Sondage Quel logiciel libre pour vos sauvegardes ?

Posté par  (site web personnel) .
Étiquettes : aucune
17
25
mai
2012
  • cp :
    313
    (13.2 %)
  • tar, à l'ancienne... y a que ca de vrai ! :
    397
    (16.7 %)
  • rsync ou autre solution de synchronisation :
    1172
    (49.3 %)
  • partimage :
    23
    (1.0 %)
  • g4u :
    1
    (0.0 %)
  • Clonezilla :
    89
    (3.7 %)
  • Backup Manager :
    77
    (3.2 %)
  • Amanda :
    19
    (0.8 %)
  • Back In Time :
    73
    (3.1 %)
  • Internet, parce que je suis un « real man » :
    116
    (4.9 %)
  • duplicity :
    99
    (4.2 %)

Total : 2379 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Lien

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

    Ça vaudrait le coup de mettre un lien pour cette histoire de vrai homme : https://en.wikiquote.org/wiki/Linus_Torvalds#1996

    • [^] # Re: Lien

      Posté par  . Évalué à 10.

      moi je faisais mes sauvegardes sur megaupload…

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Lien

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

      Complètement d'accord avec toi. D'ailleurs je l'aurais fait si cela était possible. Je t'invite donc à pertinenter cette entrée du suivi qui demande exactement cela !

  • # Backup manager

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

    Parce que ça permet d'envoyer sur ftp (fourni par ovh avec mon kimsufi) contrairement à rsync. Sinon j'utiliserais du rsync.

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: Backup manager

      Posté par  . Évalué à 2.

      Ca existe encore des hébergement sans SSH ? Kimsufi c'est pas des dediés ?

      • [^] # Re: Backup manager

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

        Si si, les kimsufi sont des dédiés…
        Donc comme toi, je suis dubitatif.

        PS: et les hébergements sans ssh sont légions…

        • [^] # Re: Backup manager

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

          Je pense que Luke Sky fait référence à un espace de stockage FTP mis a disposition par OVH pour effectuer les sauvegardes de son serveur, et non pas de son dédié lui même.
          Ça me semble être une pratique assez courante chez les hébergeurs.

          Cordialement,
          Tony

          • [^] # Re: Backup manager

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

            C'est tout à fait ça : 100Go de FTP offerts avec le dédié. Parfait pour les backups, à part que c'est du ftp.

            Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Corruption

    Posté par  . Évalué à 4.

    Quelqu'un connait une solution contre la corruption de la source ou de la destination avec rsync ?

    Avec les options par defaut rsync ne verra rien si une corruption arrive puisqu'il se base uniquement sur les informations de l'inode (taille et mtime). On peut activer la vérification avec checksum pour détecter les corruption, passer l'output en --itemize-change et grepper sur ">fc.." qui nous sortira tout les fichiers ou il y eu corruption. Le problème c'est qu'on ne sait toujours pas si c'est la source ou la destination qui est corrompue. Et on ne peut pas le savoir sauf avoir gardé un checksum des fichiers lors du dernier incrément.

    Bref faut pas mal scripter pour avoir un truc un peu robuste, et j'ai pas vu de wrapper simples pour ce problème. Quelqu'un en connait un ?

    PS: Utiliser un FS moderne qui checksum les blocks n'est pas une option envisageable. Avec un btrfs avec checksum + replication on pourra s'en passer.

    • [^] # Re: Corruption

      Posté par  . Évalué à -9.

      Du rsync over ssh devrait faire l'affaire non ?

      • [^] # Re: Corruption

        Posté par  . Évalué à 10.

        Merci de m'avoir fait découvrir rsync ! Sérieusement comment tu peux répondre à un message sans manifestement l'avoir lu…

        • [^] # Re: Corruption

          Posté par  . Évalué à 4.

          Excuses moi, j'ai effectivement mal compris ton poste, et en le relisant j'avoue être passé complètement à côté. Désolé.

    • [^] # Re: Corruption

      Posté par  . Évalué à 1.

      J'ai rencontré le même problème que toi ; après beaucoup de recherches je n'ai pas trouvé de solution existante, j'ai donc développé moi-même une application qui fait tout ça : calcul et conservation du checksum avant la sauvegarde, copie, calcul et conservation du checksum à l'arrivée. Le problème c'est que les opérations de vérification possibles lors de la sauvegarde sont assez complexes (beaucoup de cas à prévoir).

    • [^] # Re: Corruption

      Posté par  . Évalué à 4.

      Il me semble qu’Unison fait ça. Personnellement, je l’utilise surtout parce que contrairement à rsync, il est bidirectionnel.

    • [^] # Re: Corruption

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

      Il y a un patch fourni avec rsync (et donc non compilé par défaut) qui permet de sauvegarder les checksums des fichiers transférés, et éventuellement s'en servir lors des transferts suivants. D'ailleurs BackupPC utilise ça en guise de cache.

      Je n'ai pas creusé plus, mais peut-être est-il possible de coupler ça avec une autre option afin d'avoir le comportement que tu souhaites (cad, vérification de la sauvegarde).

      Au passage, je n'ai pas compris pourquoi ce genre d'option n'est fournie avec le source d'rsync que sous forme de patch, et pas dans la branche "standard", si quelqu'un a une explication je suis preneur !

      alf.life

    • [^] # Re: Corruption

      Posté par  . Évalué à -1.

      Il faut envoyer les informations par2 ou zfec qui devraint te permettre d'identifier les corruptions ou de réparer.

  • # Bacula

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

    Bonjour,
    Est-ce normal que Bacula n'est pas dans la liste ???
    http://www.bacula.org

    • [^] # Re: Bacula

      Posté par  . Évalué à 3.

      Non.

      Là j'ai l'impression que le choix se limite plus ou moins à des sauvegardes pour le PC de la maison, ou un serveur isolé, plus que pour une sauvegarde d'entreprise (je ne connais pas tout ce qui est proposé, c'est pas mon boulot, mais cp ou rsync, euh… ça me semble léger, à moins de développer une floppée de scripts avec, mais dans ce cas, pourquoi ne pas utiliser un outil tout fait?).

      • [^] # Re: Bacula

        Posté par  . Évalué à 1.

        BackucpPC permet de sauvegarder plusieurs serveurs à la fois.

      • [^] # Re: Bacula

        Posté par  . Évalué à 2.

        Je ne vois pas en quoi Clonezilla serait plus adapté que Bacula à un usage grand public :-/

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Il manque rsnapshot

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

    Un must pour moi!

  • # rien

    Posté par  . Évalué à 10.

    Les sauvegardes, c'est comme les freins.
    C'est pour les mauviettes.
    :)

  • # rdiff-backup

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

    Ça marche pas trop mal, ça passe dans du ssh, et vu que ça ne sauvegarde que la différence, c'est pas trop gourmand en ressources. du coup a un miroir du disque + un historique ce qui permet de récupérer les fichiers dans leur état à une date précise, ou de voir ce qui a été modifié (en cas d'attaque soupçonnées par exemple).

    • [^] # Re: rdiff-backup

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

      c'est absolument parfait, il suffit d'avoir 2 PC, et on peut sauvegarder l'un sur l'autre par réseau. Quoi demander de plus ?

    • [^] # Re: rdiff-backup

      Posté par  . Évalué à 0.

      je plussoie fortement j'adore rdiff-backup simple permet le backup distant via SSH jl'utilise pour mas backup journalièrement juste les rapports un peu abscons mais il y'a certains scripts python qui les mettent sous une forme bien plus "lisibles"

      sinon je suis en pleine période de tests de BURP

  • # rdiffbackup

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 25 mai 2012 à 17:16.

    Après nous être "pris la tête" avec Amanda, un lecteur de bande, un jeu de 10 bandes tournantes pour conserver 10 jours d'historique, et pour finir par une panne dudit lecteur, impossible à remplacer à un prix raisonnable, nous avons opté pour la solution suivante :
    - deux disques dur usb 2"5 de 1 To
    - rdiff-backup

    On alterne sur les deux disques, l'un d'eux part tous les soirs avec le responsable de la sauvegarde. On maintenant plus d'un an d'historique, la garantie de pouvoir faire évoluer simplement le système, pas de dépendance à un hardware spécifique… que du bonheur. Vive le libre.

  • # git push

    Posté par  . Évalué à 6.

    Qu'est-ce qu'il y a d'important qui ne soit pas dans git ?

    • [^] # Re: git push

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

      La rotation des backups ? => ne pas avoir besoin de restaurer un truc depuis la nuit des temps mais au plus d'il y a un mois ?

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: git push

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

        git peut très bien gérer ça ;)

        http://bogdan.org.ua/2011/03/28/how-to-truncate-git-history-sample-script-included.html

        Je suis un grand fan de git. Ça me permet d'accéder à mes données de partout et de gérer les versions et conflits de versions. Cerise sur le gateau, ça réplique :) C'est parfait!

        • [^] # Re: git push

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

          [Git]est parfait!

          Il me semble qu'il ne sauvegarde pas les dates, si?

          De plus, pour sauvegarder des données utilisateur pourquoi pas, mais s'il s'agit de sauver un système, il vaut mieux penser à autre chose/.

          • [^] # Re: git push

            Posté par  . Évalué à 4.

            Il me semble qu'il ne sauvegarde pas les dates, si?
            T'as pas le timestamp de l'inode mais t'as la date du commit.
            Bon cela dit je reconnais que c'était limite un troll.

            De plus, pour sauvegarder des données utilisateur pourquoi pas, mais s'il s'agit de sauver un système, il vaut mieux penser à autre chose/.

            Ça dépend ce que tu appelles sauver un système. Perso je considère que l'OS lui-même en cas de crash disque ou autre ça va plus vite de le réinstaller que de le restaurer, en plus ça permet de repartir d'une version plus récente. Et concernant sa configuration (en gros /etc) justement c'est très sympa de la bourrer dans git parce que ça permet de reprendre l'historique de tes /etc/httpd/conf.d/* ou de restaurer la version précédente de /etc/resolv.conf quand dhclient vient de l'écraser alors que tu voulais pas.

            • [^] # Re: git push

              Posté par  . Évalué à 2.

              Et concernant sa configuration (en gros /etc) justement c'est très sympa de la bourrer dans git parce que ça permet de reprendre l'historique de tes /etc/httpd/conf.d/* ou de restaurer la version précédente de /etc/resolv.conf quand dhclient vient de l'écraser alors que tu voulais pas.

              Il y a un truc qui déchire des tambourins pour ça c'est svk. Tu attaque un serveur svn, tu fais de la gestion de version distribué, mais en plus tu ne modifie pas le /etc.

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

    • [^] # Re: git push

      Posté par  . Évalué à 6.

      Git est pourri, enfin pas fait pour, des que ca concerne de gros fichiers binaires donc s'en servir comme solution de backup c'est pas tip top.

      • [^] # Re: git push

        Posté par  . Évalué à -5.

        Tu peux aussi écrire un .gitignore pour ne sauvegarder que les sources et pas les binaires… enfin je suppose que si tes binaires changent tous les soirs c'est qu'ils proviennent des sources qui sont développées tous les jours.
        Bon après c'est sûr que c'est plus minutieux à préparer qu'un gros rsync bourrin du disque sans faire de distinctions…

        • [^] # Re: git push

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

          Ah, parce que toi tu ne sauvegardes que des fichiers textes ?

          • [^] # Re: git push

            Posté par  . Évalué à 1.

            Sérieux j'avais pas pensé aux fichiers genre sauvegarde gimp (x_x) …
            À ma décharge, je n'en crée pas beaucoup…

            • [^] # Re: git push

              Posté par  . Évalué à 2.

              Sérieux tu n'utilises quasiment aucun fichier binaire ? Pas fichier zip? Pas de fichier jpeg. ? Pas de fichier audio ? Etc.

              • [^] # Re: git push

                Posté par  . Évalué à 0. Dernière modification le 30 mai 2012 à 07:12.

                C'est pas que j'utilise pas, c'est que j'y avais pas pensé, là, dans la discussion… ( - _ - ')
                Euh pour jpeg et zip, mon argument au sujet des binaires compilés s'applique !
                C'est-à-dire que le zip tout comme le jpeg possède des sources quelque part.
                Cela dit même pour les fichiers sources il peut y avoir du binaire, comme ton exemple de l'audio le montre bien…

                • [^] # Re: git push

                  Posté par  . Évalué à 4.

                  Des jpeg (c'est a dire des images) avec des sources? Ah oui ca m'arrive de prendre des photos de rivieres mais autrement je vois pas trop comment tu peux faire ca ;)

                  Le sujet de la discussion etait un outil pour faire un backup de ton systeme ce qui implique systematiquement des binaires (aujourd'hui) d'ou le fait que je precise que Git bien qu'etant genial sur bien des points n'est pas du tout fait pour les fichiers binaires (merci a Batchyx pour la commande git annex je vais regarder comment ca fonctionne pour voir si cela resout certains de mes problemes ;) )

                  • [^] # Re: git push

                    Posté par  . Évalué à 2.

                    Haha, j'ai rigolé, pour les rivières : )

                    Nan mais chuis nul chuis nul, c'est tout.
                    J'avais pas pensé aux fichiers binaires multimédia voilà ( ^ ^ ;)

                  • [^] # Re: git push

                    Posté par  . Évalué à 2.

                    Des jpeg (c'est a dire des images) avec des sources? Ah oui ca m'arrive de prendre des photos de rivieres mais autrement je vois pas trop comment tu peux faire ca ;)

                    Tu sauvegarde tout au format ppm http://fr.wikipedia.org/wiki/Portable_pixmap ou svg et c'est tout ! :)

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

      • [^] # Re: git push

        Posté par  . Évalué à 6.

        Pour les gros fichiers binaires, il y a git-annex. Ça ne garde pas l'historique du fichier (seulement celui de son hash) et ça utilise rsync en dessous quand il faut transférer les données.

    • [^] # Re: git push

      Posté par  . Évalué à 2. Dernière modification le 27 mai 2012 à 02:07.

      Qu'est-ce qu'il y a d'important qui ne soit pas dans git ?

      Ben déjà les droits pour commencer.
      Ensuite la sauvegarde par blocs (Personnellement faire des sauvegardes avec des outils qui travaillent au niveau fichier ca m'a toujours laissé perplexe.)
      Après au niveau sauvegarde/restauration il y a aussi de légers défauts. Est-ce qu'on fait une branche par sauvegarde ? Une branche pour les mensuelles qu'on garde deux ans et des append dans la branche active pour les sauvegardes journalières ? Comment on cherche la bonne version d'un répertoire avant corruption ? On fait 40 rebase et on y va à la mano ? etc.

      GIT est un outil de versionning donc orienté synchronisation. Mais pour les backups c'est pas le pied a moins de le barder de tout un tas de scripts. Ca peut éventuellement être la base d'un système de sauvegarde, mais en soi c'est loin du compte.

      • [^] # Re: git push

        Posté par  . Évalué à 3.

        Est-ce qu'on fait une branche par sauvegarde ?

        Pourquoi ferait-on ça ?

        Comment on cherche la bonne version d'un répertoire avant corruption ? On fait 40 rebase et on y va à la mano ?

        Ben, git bisect.

        • [^] # Re: git push

          Posté par  . Évalué à 1.

          Pourquoi ferait-on ça ?

          Parceque des fois la sauvegarde cohérente est liée à plusieurs machines.
          En restauration il y a grosso modo trois possibilités suite à un plantage :
          a) On veut ramener un fichier ou un ensemble de fichiers dans un état antérieur (par exemple avant qu'ils ne soient écrasés ou mal écrits)
          b) On veut ramener un serveur dans un état antérieur (par exemple avant une mise à jour foireuse)
          c) On veut ramener un système dans un état antérieur (par exemple une appli et sa base de données avant un gros traitement qui a mal tourné)

          En créant une branche par sauvegarde (par exemple avec la date de la sauvegarde dans la branche), il ets très facile en lisant les commits de la branche de voir si toutes les sauvegardes se sont bien passées ce jour là, si il y a eu besoin de relancer des sauvegardes à la main, si l'opérateur est intervenu etc.
          Et ça, ça aide grandement quand on doit faire une restauration de type b) ou c).
          En plus ca permet aussi facilement de faire un clone à une date précise pour garder des sauvegardes intégrales de l'ensemble du système.

          Ben, git bisect.

          Ca ca marche si je sais déjà à quel jour j'ai un fichier ou une base non corrompue. Si je cherche la sauvegarde dans laquelle tel ou tel fichier de conf fait plus de 40 octets je suis reparti en rebase à gogo.

          • [^] # Re: git push

            Posté par  . Évalué à 3.

            De ce que j'en comprend, t'a envie de tags, pas de branches. Mais en même temps je comprend toujours pas pourquoi tu veut créer une branche par jour, même s'il n'y a rien qui t'en empêche.

            Et pour savoir qui à fait le con sur un fichier, c'est du coté de git blame (ou sa gui) qu'il faut regarder.

            • [^] # Re: git push

              Posté par  . Évalué à 2.

              Je n'avais jamais entendu parler de l'instruction blame de git, c'est juste génial. Avoir utilisé blame (blâmer) plutôt que lastmodified ou last c'est une manière d'assumer de mettre un pression sociale potentielle sur chaque développeur ;)

              • [^] # Re: git push

                Posté par  . Évalué à 3.

                Juste pour info ca existait déjà dans CVS… ;)

            • [^] # Re: git push

              Posté par  . Évalué à 1.

              De ce que j'en comprend, t'a envie de tags, pas de branches.

              Je me suis mal exprimé, j'ai besoin d'une méthode qui permette à 43 scripts de sauvegardes différents de passer à la queueleuleu dans un même bloc en disant si ils se sont bien déroulés ou pas, et si pas donnat les fichiers non sauvegardés.
              Ce bloc doit me permettre de savoir rapidement si oui ou non la sauvegarde faite un jour me permet de restaurer à l'identique l'ensemble d'une infrastructure (ie système + base de données + conf + queues + autres fichiers de conf ou utilisateurs).

              Une des solutions est de faire une branche par jour et de mettre les infos de sauvegarde dans les commits. En lisant le contenu des commits je sais tout de suite si oui ou non la sauvegarde d'une journée est bonne.

              Il y a d'autres méthodes bien sur, mais c'est moins facile de voir si à une date donnée toutes les sauvegardes se sont bien déroulées.

              • [^] # Re: git push

                Posté par  . Évalué à 2.

                Je suis toujours pas sûr d'avoir compris (c'est quoi un "bloc" ?), mais pour moi, si tu à 43 choses différentes à sauvegarder, alors tu à 43 dépots.

                Et si tu à envie de versionner l'état de tes 43 dépots, alors tu crée un autre dépot parent qui possède les 43 dépots en sous-modules. le dépot parent ne va versionner que les hash des révisions de tes 43 sous-modules, mais va le faire avec toutes les fonctionnalités de git : messages de commit, branches, tags …

                Bon après, les sous-modules, c'est pas la fonctionnalité la plus génialement faite de git, c'est un peu mal intégré avec le reste…

                • [^] # Re: git push

                  Posté par  . Évalué à 0.

                  mais pour moi, si tu à 43 choses différentes à sauvegarder, alors tu à 43 dépots.

                  Et ben vache, le jour ou je veux réconcilier tout ça je vais en baver.
                  Supposons une société qui a cloturé son bilan 2011, l'AG arrive et pour une raison X, Y ou Z les comptes sont refusés. Par exemple parce que une floppée de clients se sont plaint d'avoir été surfacturés en décembre et que du coup les actionnaires ont un poil l'impression qu'on se fout de leur gueule en présentant des chiffres mirobolants. Donc les comptes sont refusés et il faut revenir à l'état du 31 décembre (ou le plus proche possible) et refaire les comptes en provisionnant les réclamations clients.

                  Comme il est interdit de réouvrir une compta cloturée en France (c'est même une des conditions nécessaires pour qu'un logiciel de compta puisse envisager l'agrément le plus faible), il faut faire un rollback complet au 31 décembre. Entre temps il y a eu 2 mises à jour de MySQL et 127 mises à jour de PHP (oui le logiciel de compta est web 2.0). Sans compter qu'il faut aussi restaurer les ESB, les sytèmes de fichiers et les divers logiciels de déclaration à la même date sous peine de faire planter tous les traitements automatisés ou d'avoir des résultats incohérents.

                  De là deux solutions. Soit tu sauvegardes tout ce qui a été fait depuis la cloture en bloc, tu restaures tout au 31 décembre en bloc et de là on avance pas à pas. Soit tu as 43 sauvegardes distinctes et là tu vas jouer à "komenkonfè" et "keskimanke" pendant deux mois (ce qui va ennerver les actionnaires et les dirigeants, donc probablement couter son poste au DSI qui avant de partir aura une pensée émue pour toi - le chargé de backup).

                  Même problème en cas d'incendie qui détruit tout le système ou en cas de panne qui existe depuis un moment mais dont on ne se rend compte qu'aujourd'hui parceque le traitement concerné n'est lancé que tous les trimestres.

                  • [^] # Re: git push

                    Posté par  . Évalué à 2.

                    De là deux solutions. Soit tu sauvegardes tout ce qui a été fait depuis la cloture en bloc, tu restaures tout au 31 décembre en bloc et de là on avance pas à pas. Soit tu as 43 sauvegardes distinctes et là tu vas jouer à "komenkonfè" et "keskimanke" pendant deux mois

                    Et bien tu prend la première solution, qu'est ce qui t'en empêche ?

                    Ah, et pour revenir au 31 décembre en bloc, c'est cd $depot_parent && git checkout $le_commit_du_31_decembre && git submodule update (et peut-être un git submodule foreach git push, ça dépend comment tu organise tes dépots)

                    • [^] # Re: git push

                      Posté par  . Évalué à 1.

                      && git checkout $le_commit_du_31_decembre

                      Et bien tu prend la première solution, qu'est ce qui t'en empêche ?

                      C'est donc officiel, je ne parle pas français.
                      Dans mon exemple, la première solution (à savoir celle ou on fait un branche par jour) que cette branche soit au niveau 1, 2 ou 10 d'une arbo de sous modules est la bonne solution.

                      Sauf que dans le cas ou j'utilise les sous modules il faut en plus que je trouve un moyen de ma'assurer que ma journée de sauvegarde est bien cohérente (si pour une raison ou une autre un des sous modules n'a pas commité au 31, alors submodule update va remonter silencieusement la dernière bonne version connue, qui peut dater.)

                      Donc quitte à faire une branche par sauvegarde, autant le faire à fond.

                      • [^] # Re: git push

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

                        C'est vrai, faire un submodule par script/activité/peuimporte c'est pas forcément la meilleure solution, puisque tu veux garder ton système en un tout cohérent; tout à la version du 31 décembre ou tout à la version du 3 Août.

                        Par contre quand tu dis branche, tu veux dire _branch_er par rapport à quoi ? Tu veux pas parler de commit tout simplement ?

                        • [^] # Re: git push

                          Posté par  . Évalué à 1.

                          Par contre quand tu dis branche, tu veux dire _branch_er par rapport à quoi ? Tu veux pas parler de commit tout simplement ?

                          Non, j'utilise les commits pour avoir un rapport sur le comportement des différentes sauvegardes.

                          Par exemple j'ouvre le bloc de sauvegarde du jour avec un git branch, chacun des 43 systèmes à la queueleuleu fait un merge puis un commit de sa sauvegarde (en donnant la liste des éléments non sauvegardés, les soucis, les incohérences dans le commit), puis on fait les traitements de fin de journée on note leur résultat dans un dernier commit sur la branche.
                          Ensuite on ouvre une nouvelle branche pour les sauvegardes du lendemain.

                      • [^] # Re: git push

                        Posté par  . Évalué à 2.

                        Sauf que dans le cas ou j'utilise les sous modules il faut en plus que je trouve un moyen de ma'assurer que ma journée de sauvegarde est bien cohérente (si pour une raison ou une autre un des sous modules n'a pas commité au 31, alors submodule update va remonter silencieusement la dernière bonne version connue, qui peut dater.)

                        git submodule update ne va pas "prendre la dernière version connue", elle va prendre la version associée au commit courant. Autrement dit, celui du 31 décembre.

                        Si un submodule n'à pas été changé par le commit du 31 décembre, tu peux t'en rendre compte en regardant le commit. Tu peux aussi mettre l'information dans le message de commit pour qu'elle soit plus visible…

  • # Bouquin sur le sujet, et info sur BackupPC

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 25 mai 2012 à 17:50.

    J'ai choisi BackupPC après avoir lu le bouquin O'Reilly "Backup and Restore" : http://shop.oreilly.com/product/9780596102463.do
    Le bouquin est plutôt à destination des gens qui gèrent un petit parc informatique je trouve. il est parsemé d'anecdotes qui motivent bien à faire des backups corrects ET des tests de restauration.

    BackupPC permet de faire des sauvegardes régulières de différentes machines avec une mise en commun des fichiers pour gagner de la place (C'est fait pour sauvegarder sur le disque du serveur qui l’exécute). Il y a une interface web pour surveiller le tout et se balader dans les sauvegardes pour récupérer juste un fichier ou un répertoire sans faire toute une restauration. Pour un poste perso il y a sans doute plus simple par contre.

  • # dar

    Posté par  . Évalué à 5.

    http://dar.linux.free.fr/
    Parce que, entre autres:
    --diff
    −−include−ea (acls des serveurs samba)
    --execute (pour graver)
    --key (pour la sécurité)
    --alter (pour la discrétion)
    −−backup−hook* (pour postgresql)
    Le support est très réactif (voir la ml).
    Pour certains serveurs, je "darre" le / sur plusieurs dd externe alternés (sauf proc et sys bien sur).

  • # Areca Backup

    Posté par  . Évalué à 2.

    Areca Backup : sympa, java.
    J'aime bien.

  • # A propos de dev

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

    De /dev en fait.

    Il me semble que /dev/ contient plein de trucs, et qui ne sont pas forcément des trucs à backuper.

    Pour les partitions, elles sont montées ailleurs.

    donc, pour /dev? quelle serait la bonne politique?

    C'est vrai que tout dépend si l'on veut pouvoir remonter un serveur à l'identique, ou uniquement remettre en place les données et la config, et avoir un truc qui tourne.

    Moi, j'utilise rdiff-backup, et je n'ai pas encore eu l'occasion de tester mes backups. Déjà parce que j'ai vérifier que les fichiers dont j'avais besoin étaient disponibles, et j'ai eu besoin un jour d'aller y chercher une version de la veille :)

    Une fois, dans un conteneur OpenVZ, j'ai fait un chmod -R 750 / et heu… ça va très vite j'avais le choix entre utiliser les backup, ou laisser tomber puisque je voulais tester la gestion des mails, et que je n'avais donc encore rien fait. Et j'ai toujours rien fait, j'ai effacé le conteneur et voilà. Dommage, c'était une bonne occasion de tester la remise au propre d'un conteneur complet. Histoire de voir ce qui manque pour la restauration…

    Donc, le /dev/, vous le backupez ou pas? et comment?

    Bonne soirée
    G

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: A propos de dev

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

      Je ne sauvegarde pas le système, seulement /etc dans lequel il y a des données importantes.
      Sur une machine récente, le système s'installe en un quart d'heure, un autre pour reconfigurer le système en s'aidant de l'ancien /etc et une demi-heure pour installer les logiciels complémentaires et faire les updates.

      Pour sauver le système, dd est une solution, mais si on est obligé de changer du matériel par quelque chose de nouveau, on peut avoir de gros ennuis.

      • [^] # Re: A propos de dev

        Posté par  . Évalué à 2.

        Pour sauver le système, dd est une solution, mais si on est obligé de changer du matériel par quelque chose de nouveau, on peut avoir de gros ennuis.

        Et je dirai même plus: souvent quand t'as un gros crash avec perte du système, t'as un disque dur, une alim et/ou une carte mère à changer, justement…

    • [^] # Re: A propos de dev

      Posté par  . Évalué à 1.

      Donc, le /dev/, vous le backupez ou pas? et comment?

      Non, mais si j'avais à le faire, je regarderais du côté de cpio. Les initrd du noyau Linux sont des archives cpio compressées, et c'est comme ça que de nos jours on charge les systèmes live (un installeur par ex. ) en RAM.

    • [^] # Re: A propos de dev

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

      Il est re-peuplé au boot sous les debian like il me semble, il y a même un joli message "Populating /dev" ….
      Pas besoin de les sauvegarder sur ces distributions ! ;o)

      Fuse : j'en Use et Abuse !

  • # dump

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

    Comme j'utilise un vrai système d'exploitation (FreeBSD) il y a déjà un outil de sauvegarde simpliste mais robuste installé dessus. Mon schéma de sauvegarde consiste à faire une sauvegarde de niveau 0 quand ça me pète, une sauvegarde de niveau 1 tous les mois, et des sauvegardes de niveau 2-9 le reste du temps.

    • [^] # Re: dump

      Posté par  . Évalué à 0.

      A qui s'adresse ce commentaire sur les "vrais OS"?

      • [^] # Re: dump

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

        A qui s'adresse ce commentaire sur les "vrais OS"?

        Aux gens qui utilisent un OS qui n'est pas livré avec un outil de sauvegarde raisonnable.

    • [^] # Re: dump

      Posté par  (Mastodon) . Évalué à 4.

      la commande dump existe sous linux aussi et supporte ext2/3 et 4.

      Pour les autres FS moins courant je ne sais pas.

  • # Hammer

    Posté par  . Évalué à 3.

    Le système de fichier de dragonflyBSD et sa fonctionnalité de mirroring.

  • # Backup Manager

    Posté par  . Évalué à 3.

    Je me suis tourné vers backup manager pour éviter de devoir scripter moi-meme (ca n'aurait pas été dur a faire mais bon..)

    J'ai ajouté par dessus monit qui permet de monitorer toutes sortes de ressources: monit parse les fichiers de log de backup-manager, et en cas de soucis (notamment parce que les machines de backup sont auto heberges), hop un petit mail.

    Ca permet d'avoir l'esprit tranquille.

    • [^] # Re: Backup Manager

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

      C'est vrais que c'est une bonne interface graphique, et au moins les fichiers restent lisible avec un simple navigateur de fichier.

  • # zfs ses snapshots et la fonction send receive

    Posté par  (Mastodon) . Évalué à 4. Dernière modification le 26 mai 2012 à 10:20.

    sur la machine source, snapshots automatiques chaque heure/jours avec convention de nommage simple (en gros date +".date +").

    on envoie (zfs send) un incrémental entre ce snapshot et le précédent sur la machine de backup via ssh.

    on détruit automatiquement x snapshots suivant l'espace que ça prend et la volatilité du fs.

    Sur la machine de backup on fait de même mais avec une rétention plus longue.

    1x par semaine, on un snapshot complet, pas un incrémental.

    on rince, et on répète jusqu'à plus soif.

    Note1: idéalement la machine qui backup utilise aussi du ZFS et dans une version identique sinon supérieure ce qui permet de pouvoir naviguer dans les fichiers et faire des restores de fichiers individuels. Mais pour du disaster recovery, les snapshots zfs peuvent simplement être envoyés et stockés sous forme de fichiers sur un filesystem d'un autre type et ils ne seront utilisable qu'en cas de restore complet du volume via un zfs receive.

    Note2: on peut faire de même mais au lieu d'envoyer via ssh, on envoie sur un disque externe et on en fait tourner plusieurs. C'est ce que je préfère pour la maison au final avec un échange de disque dur avec la famille quand je leur rends visite pour avoir une copie de moins de x mois en cas d'incendie.

  • # tar + openssl + lftp

    Posté par  . Évalué à 2.

    Ya que ça de vrai !

  • # Arkeia Network Backup

    Posté par  . Évalué à 1.

    C'est une solution de sauvegarde en réseau pour les entreprises qui n'est pas open-source (à part un outil de restauration permettant de récupérer les données sans le logiciel) mais dont il existe une version gratuite accessible sur http://www.arkeia.com/fr/freelinuxbackup

    Les avantages de cette solution sont sa simplicité d'utilisation grâce à son interface graphique Web (il y a aussi une CLI) sa capacité à sauvegarde sur disques, bandes et cloud ainsi que sa déduplication de données.

    Arkeia Software sera sur Solutions Linux (au CNIT du 19 au 21 Juin).

    Frederic
    Disclaimer : je fais partie de la société Arkeia Software

  • # Brasero

    Posté par  . Évalué à 1.

    J'ai voté rsync parce que je m'en sers pour envoyer quelques petits fichiers sur un dédié (carnets d'adresses, fichiers importants qui changent souvent, factures).

    Mais pour les grosses données (photos, éventuellement musiques et vidéos), j'utilise brasero. Enfin il faudrait que je le fasse…

  • # Tarsnap - Online backups for the truly paranoid

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

    J'utilise tarsnap, parce que je suis un vrai parano (mais pas trop).

    http://www.tarsnap.com/

  • # Deja-Dup

    Posté par  . Évalué à 2.

    https://live.gnome.org/DejaDup

    Qui est bien fait, et qui fonctionne sans avoir à se galérer.

    • [^] # Re: Deja-Dup

      Posté par  . Évalué à 2.

      Pour ce dernier, il faut cocher "duplicity", sur lequel il est basé.

  • # Un peu de tout

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

    tar, dar, duplicity, rsync, mercurial, email, cpold, scp.

  • # J'ai répôndu rsync ou autre ...

    Posté par  . Évalué à 0.

    Personnellement, c'est plus une solution tournant avec burp (http://burp.grke.net). L'architecture utilise donc burp en client sous Linux ou Windows 2008 et burp-server installé sur une machine qui utilise moosefs en stockage avec un goal de 4. Donc rapidité de sauvegarde et sécurisation de la sauvegarde par multiple copie sur des serveurs répartis sur plusieurs bâtiment reliés par de la fibre :-). Restauration rapide car lecture simultanée sur les 4 serveurs de stockages :-)

  • # bacula

    Posté par  . Évalué à 4.

    http://bacula.org ne figurant pas ici, je me permet de le rapeller. C'est probablement l'un des plus complets. Je l'ai utilisé des années, j'en suis tres satisfait

  • # NanoTech

    Posté par  . Évalué à 0.

    4.5% de "real men", j'ai du mal à y croire.

  • # Des snapshots avec rsync

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

    http://www.mikerubel.org/computers/rsync_snapshots/

    rsync, combiné avec cp -al, permet d'avoir des snapshots des données sauvegardées, tout en étant économe en espace disque, voici par exemple un du -sh de mon disque de backup:

    1.1G    .Fenrir.20110611
127M    .Fenrir.20110616
325M    .Fenrir.20110620
72M     .Fenrir.20110909
606M    .Fenrir.20110930
607M    .Fenrir.20111009
1.5G    .Fenrir.20111024
141M    .Fenrir.20111027
19G     .Fenrir.20111113
84M     .Fenrir.20111118
654M    .Fenrir.20111219
11G     .Fenrir.20120115
7.6G    .Fenrir.20120203
155M    .Fenrir.20120218
362M    .Fenrir.20120226
49M     .Fenrir.20120229

    (J'ai changé de hostname depuis)

    Chacun de ces dossiers contient toute l'arborescence de mon $HOME à l'instant ou le backup a été fait. Pour libérer de l'espace disque, c'est on ne peut plus simple: on supprime (avec rm) n'importe lequel de ces dossiers, sans affecter aucun des autres snapshots (c'est la magie des hard links…).

    • [^] # Re: Des snapshots avec rsync

      Posté par  . Évalué à 4.

      rsync, combiné avec cp -al

      Ca va faire 10 ans que --link-dest existe ;)

      • [^] # Re: Des snapshots avec rsync

        Posté par  . Évalué à 1.

        Tu vient de me faire découvrir ca, moi qui me disait que j'allais passer à rsnapshot. Du coup, je suis en train de me demander quel est l'interet de ce dernier…

      • [^] # Re: Des snapshots avec rsync

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

        Oui, et je m'en sers. C'est indiqué dans le lien que j'ai donné (ce flag n'existait pas à l'époque où il a été écrit, ça a été rajouté plus tard).

  • # D2D2T

    Posté par  . Évalué à 1.

    L'utilises tout simplement
    un D2D2T croisé

    machine 1 à 3 sont sauvées. 1 sur 2 / 2 sur 3 & 3 sur 1
    la machine 1 est sauvegardée aussi sur tape ainsi que le montage depuis 2 et depuis 3

    disk to disk to tape

    donc sur la sauvegarde bande c'est machine 1 + machine 2 + machine 3
    (3 formats Tar à la suite)

    il suffit par exemple pour aller sur le 3ième fichier de faire 

    mt fsf 2
tar tf /dev/st0

  • # backupninja

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

    https://labs.riseup.net/code/projects/backupninja

    BackupNinja c'est chuper, ça permet de tout automatiser les dumps mysql, sauvegarder les paquets debian installés, les repositories svn, et envoyer tout ça avec rdiff-backup, rsync, duplicity, etc.

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Contemplation

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

    Un disque dur qui lache doit etre vu comme le symbole de l'impermanence et du caractère transitoire des données que nous stockons. Il faut voir les représentations faites par baobab comme des mandalas. Ne pas faire de sauvegarde permet de combattre l'attachement.

    Nasty thoughts are like buses - you don't get one for ages and then a whole army arrive at once.

Suivre le flux des commentaires

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