Journal Mon Backup de backup

Posté par  . Licence CC By‑SA.
Étiquettes :
23
25
juil.
2016

Salut Nal,

Voilà des mois que je tourne en rond avec cette histoire, alors je me dis que l’écrire me donnera peut-être des idées…

Je fais un backup journalier de plusieurs machines avec backintime (très bien pour la sauvegarde incrémentale avec rsync :-)) sur un NAS en RAID 6… Ça marche et c’est bien sympa depuis des années (6 ans ?) : j’ai accumulé plus de 2 To de backup malgré les zillions de hardlinks. Mais, tout RAID 6 qu’est mon NAS, on sait qu’il y a quand même un risque de perdre des données.

Donc je tente depuis quelques années de sauvegarder ce NAS contenant mon backup… Et là… c’est l’échec ! Je ne me souviens (hélas) pas de tout ce que j’ai essayé de mettre en œuvre, mais voilà les deux solutions qui me paraissaient les plus crédibles (et avec lesquelles je suis pourtant en échec !), suivi de mes (tristes) plans d’avenir…

première idée : un bon vieux rsync…

J’ai donc essayé rsync -aPHS (et même en premier lieu rsync -aPHSc car je suis fou). Théoriquement ça doit marcher c’est la solution pour ce genre de backup !

Bilan ?

Le bilan est pas tout à fait définitif… Après 1,5 an (oui oui) de backup en ayant rajouté 256 Go de swap à mon NAS (car, oui, l’option -H de rsync a aspiré les 2 Go de mémoire du NAS en un rien de temps), le backup n’est… pas fini ! loin de là ! Seulement 1,2 Go sur les 2 Go…

C’est évidemment la sauvegarde des hardlinks qui est interminable ! Mais je ne peux pas sauvegarder sans tenir compte des hardlinks : il me faudrait au moins une 12aine de To !

Après recherche, fonçons vers la modernité : BUP

Bup, c’est cool, ça utilise GIT et tout et tout… Donc nativement ça déduplique (au niveau des chunks et non plus des fichiers : c’est top !) en plus que ça sauvegarde. Trop cool !

Je fais donc un test sur une petite partie de la totalité du backup (~20 % du total des hardlinks et des octets).

J’ai commencé le 7 mai à faire un bup index après avoir précautionneusement remis un swap de 256 Go (indispensable, car les 2 Go de RAM ont fondu comme neige au soleil).

Bilan ?

Il n’est pas tout à fait définitif non plus… Aujourd’hui (25 juillet), 12 Go de RAM+swap sont utilisées et le bup index n’est pas fini… (pour ceux qui ne connaissent pas du tout bup, bup index cherche juste à faire un catalogue de ce qu’il faut sauvegarder. S’en suit une autre opération qui consiste a effectivement sauvegarder : bup save)

Que faire ?

Oui, je suis bien embêté…

Mes plans pour l’avenir ? Mon plan principal est de retourner vers rsync. Sachant que je n’arrive pas à tout sauvegarder (en 1,5 ans 1,2/2 To ont été sauvegardés quand même), je me dis que je peux peut-être faire un rsync des fichiers les plus récents en premier (en suivant quelque chose comme : https://coolaj86.com/articles/how-to-rsync-files-by-date-or-by-size.html).

Autres idées (dures à exploiter avec mon NAS peu puissant et assez fermé) : Brtfs ou ZFS sur le support de sauvegarde… J’ai peur d’arriver, au terme de gros efforts de mise en œuvre, au même résultat : sauvegarde interminable.

Et vous ? Vous les gérez comment vos backups de backups incrémentaux (avec les joies des zillions de hardlinks) ?

  • # Quel est l'utilisation de ta sauvegarde de sauvegarde?

    Posté par  . Évalué à 6.

    Si la destination de cette sauvegarde est purement de l'archivage une solution de type «glacier d'amazon» ou sauvegarde sur bande, avec un simple «cp/dd/…» ou approchant est une solution envisageable.
    Si cette sauvegarde doit rester accessible, les outils les plus simples sont souvent les plus adapté sur les gros volumes.

    • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

      Posté par  . Évalué à 5.

      Je préfère ne pas faire un backup dans les nuages pour trois raisons (dans le désordre) :

      • faut tout chiffrer, et sur mon NAS ça va prendre des siècles
      • il va me falloir plein de To si les hardlinks ne sont pas maintenus → coût exorbitant
      • je n'aime pas trop l'idée de laisser mes données à d'autres (je tente de m’auto-héberger quand c'est à ma portée).

      Pour ce qui est des bandes : le coût est beaucoup trop élevé pour moi… Les disques durs sont plus à ma portée (même plusieurs), laissés chez des proches très distants…

      • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

        Posté par  (Mastodon) . Évalué à 9. Dernière modification le 25 juillet 2016 à 14:51.

        Tu as des hardlinks pour éviter la copie de fichiers identiques. Il n'est nullement besoin de copier x fois le même fichier sur ton backup de backup !

        Si ton ensemble pèse 2To, ça veut dire que t'as 2To de data, pas plus. Donc un bon disque de 3To dans le commerce, un cp -a, et ça te coûte 2To / 100Mo/s = 20000 secondes soit 6h grosso-merdo. Je te le laisse à une nuit.

        Ton backup de backup aura ainsi une copie de toute la structure de ton arborescence de backups rsync.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

          Posté par  . Évalué à 2.

          Il faut peut-être que je me repenche sur la question du cp -al.

          Il me semble avoir fait des essais puis abandonné, car :

          • c'était hyper long (j'ai abandonné des semaines après le commencement). Je crains que le problème reste le même que le -H de rsync : maintenir le dico des hardlink/inodes en mémoire.
          • ça nécessite une validation postérieure pour vérifier que la sauvegarde est conforme.

          Je vais sans doute refaire des tests avec cp…

          • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

            Posté par  . Évalué à 2.

            Et dd ?

          • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

            Posté par  . Évalué à 2.

            c'était hyper long (j'ai abandonné des semaines après le commencement).

            Essaye peut-être par lots, afin de valider la méthode ? Tout à l’heure j’allais te répondre que cp -a devrait copier les hardlinks tel quel (ce que tu veux) mais après lecture du man ce n’était plus si évident… m’enfin de mémoire il me semble bien que c’est le cas.

            De toute façon 2To c’est 2To, que tu utilises dd, cp, rsync ou autre ça serait forcément relativement long de tout dupliquer.

            Un autre avantage de le faire par lots c’est que tu peux éventuellement virer quelques trucs devenus sans intérêts au passage. Après je conçois tout à fait que l’on veuille « tout garder » mais bon, ça fait forcément de la « manutention », comme des meubles ou des bibelots !

            • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

              Posté par  . Évalué à 1.

              Je ne suis pas sûr, mais je pense qu'un cp -a par lots fera perdre le bénéfice des hardlinks (entre les fichiers qui sont dans des lots différents).

              Mais j'ai prévu de tester à nouveau le cp -a ce soir… Je vous dirais dans 1 an là où ça en est :-)

          • [^] # Re: Quel est l'utilisation de ta sauvegarde de sauvegarde?

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

            Non, cp -a tout court ! Pas la peine d'aller chercher plus loin !

            Ça préserve tout (a = archive !), les links, les droits, les dates, tout. C'est fait exactement pour ce que tu cherches à faire.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # .

    Posté par  . Évalué à 5.

    Le modèle précis du nas pourrait être intéressant. Et tu sauvegardes où ?

    Un backup c'est normalement une opération qui est "simple". Utiliser 258 Go de ram pour un backup de 2000 Go (rapport 1/8) ça me parait être le signe que ce n'est pas la bonne méthode.

    De plus 1 an et demi ça fait une cinquantaine de millions de secondes. 1,2 To / 50 millions de secondes : 24 ko/s ? Là aussi ça ne me semble pas être la bonne méthode.

    Sans le -H la consommation de ram est plus classique ?

    Et le -S ?

    Tu devrais essayer différentes combinaisons sur une petite volumétrie pour trouver une meilleure combinaison.

    As-tu la possibilité d'utiliser un simple cp -al ?

    • [^] # Re: .

      Posté par  . Évalué à 1.

      Le débit est effectivement très faible… Ce n’est pas du débit pur, sachant que pour les hardkinks il faut stocker une sorte de dico des inodes en mémoire. En fait, j’ai l’impression qu’il diminue fortement avec le temps (sans doute dès qu’il utilise le swap ???)

      Hélas, je ne me souviens pas de tout ce que j’ai essayé ! Mais il me semble bien avoir commencé par un cp -al, qui prenait aussi son temps, mais que j’ai interrompu pour profiter des différents avantages de rsync (le contrôle en particulier).

      J’ai fait des tests sans -H (mais ils étaient un peu vains, car je n’avais pas la place dispo pour tout sauvegarder). Je me souviens que c’était plus performant. Je sais plus si j’ai essayé le sans le -S… Je vais peut-être refaire des tests sans -S…

      Bon, sinon je ne suis pas entré à fond dans les détails, car il est vrai que la config est un peu alambiquée !
      Le NAS de backup, qui ne fait exclusivement que du backup est un QNAP TS-509 Pro (Celeron 1,6 Ghz + 1 Go RAM)… Il est relié en NFS à mon réseau local où (et c’est là que ça se complique) un autre NAS (Synology DS713+ core duo 2.13Ghz + 2Go de RAM) fait le rsync sur un disque (SATA HD 7200 tr/min) relié en e-sata.

      Pourquoi aussi compliqué ? Parce que le résultat était encore plus lent en faisant directement depuis le NAS de backup (et en plus les nouveaux backups devenaient eux aussi interminables).

      • [^] # Re: .

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

        Mes 5 centimes: Je vois qu'un des 2 NAS est un Synology, et j'ai un NAS synology (212j, donc clairement pas une bête de course).
        J'utilise leur application Hyperbackup intégrée dans DSM 6 pour copier et chiffrer le contenu de mes backups (sur un compte Hubic dans mon cas). Leur solution maison est pas mal du tout: chiffrement possible, et conservation de l'historique des fichiers. Par contre, pour les hard link, c'est foutu je pense. Mais peut-être une piste à creuser…

      • [^] # Re: .

        Posté par  (Mastodon) . Évalué à 4. Dernière modification le 26 juillet 2016 à 11:27.

        QNAP TS-509 Pro (..) relié en NFS à mon réseau local ( …) un autre NAS (…) fait le rsync sur un disque relié en e-sata.

        C'est pas si compliqué que ça :-)

        une sorte de dico des inodes en mémoire.

        Ce sont les dentries, qui n'existent que pour ça. Et c'est sur ça que joue les liens. La dentry référence donc un nom de fichier à un numéro d'inode et à son dossier parent. Le fait de stocker à part les noms remonte à l'invention des hardlinks (c'est aujourd'hui critiqué, il me semble amha toussa) d'avoir séparé les deux, et la notion même de hardlink est critiquée (du moins, à ce niveau là) Les inodes, quant à elles, contiennent des méta-données (permissions bases par exemple, bref, "l'index du noeud")

        Le débit est effectivement très faible… Ce n’est pas du débit pur, sachant que pour les hardkinks il faut stocker une sorte de dico des inodes en mémoire. En fait, j’ai l’impression qu’il diminue fortement avec le temps (sans doute dès qu’il utilise le swap ???) (…) Hélas, je ne me souviens pas de tout ce que j’ai essayé !

        Tu devrais essayer un bon vieux logiciel tel que cpdup qui est fait pour ça :

        The cpdup utility makes an exact mirror copy of the source in the destination, creating and deleting files and directories as necessary. utimes, hardlinks, softlinks, devices, permissions, and flags are mirrored

        à priori il rencontre la même difficulté que toutes autres solutions lorsqu'il s'agit de créer des hardlinks : maintenir la table est couteux en ressources. Mais il n'a pas ce problème lorsqu'il s'agit de copier une structure existante, avec de nombreux hardlinks déjà présents. Si ceci, après tes tests, se confirme, alors tu as une réponse à ta question initiale « mon backup de backup »

  • # méthode brute ?

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

    Une question et quelques remarques :

    Tu essayes de rsyncer/buper par le réseau ou tu as branché un disque externe au NAS ?

    BTRFS ou ZFS ne vont pas vraiment te sauver pour les données existantes.

    M'est avis que tu mélanges archivage et sauvegarde, que c'est pas bien et la source de ton problème.

    La question que je me poserais d'abord, c'est est-ce que j'ai besoin de tout mon historique des backups depuis les x années que je fais ce rsync ?

    Personnellement, en dehors d'une zone distincte qui est archivée séparément (avec notemment des scans de papiers importants et photos/vidéos), je fais des purges régulières de mes backups. Je pars du principe que si je ne suis pas capable de me rappeler ce à quoi j'avais accès il y'a X mois, alors ça ne me sert à rien de les garder car je ne saurais pas qu'elles sont dans mes backups dans plusieurs années et ne chercherai jamais à les restorer.

    As-tu testé de dupliquer ton filesystem avec dd tout simplement ? ça implique au minimum de mettre tes points de montage en readonly et du coup de mettre en pause tes backups mais j'imagine qu'en quelques jours ce serait réglé.

    • [^] # Re: méthode brute ?

      Posté par  . Évalué à 1.

      Une question et quelques remarques :

      Tu essayes de rsyncer/buper par le réseau ou tu as branché un disque externe au NAS ?

      J’ai un peu répondu ci-dessus : https://linuxfr.org/users/beurt/journaux/mon-backup-de-backup#comment-1666715

      Le backup se fait via le réseau, sur un disque externe (e-sata).

      M'est avis que tu mélanges archivage et sauvegarde, que c'est pas bien et la source de ton problème.
      La question que je me poserais d'abord, c'est est-ce que j'ai besoin de tout mon historique des backups depuis les x années que je fais ce rsync ?

      Ma réponse est plutôt oui. Je hais de perdre des données, notamment parce que j’en ai déjà perdues (trop).

      Programmer leur perte n’est pas vraiment la solution à mon problème : je cherche à sécuriser ma sauvegarde ! Voilà pourquoi je ne pratique volontairement pas non plus le « pruning »…
      (De toute façon la quantité de données gagnée de cette façon est marginale, par contre pas le nombre de hardlinks !)

      Personnellement, en dehors d'une zone distincte qui est archivée séparément (avec notemment des scans de papiers importants et photos/vidéos), je fais des purges régulières de mes backups. Je pars du principe que si je ne suis pas capable de me rappeler ce à quoi j'avais accès il y'a X mois, alors ça ne me sert à rien de les garder car je ne saurais pas qu'elles sont dans mes backups dans plusieurs années et ne chercherai jamais à les restorer.

      As-tu testé de dupliquer ton filesystem avec dd tout simplement ? ça implique au minimum de mettre tes points de montage en readonly et du coup de mettre en pause tes backups mais j'imagine qu'en quelques jours ce serait réglé.

      Non, je n’ai pas (encore) pensé au dd, ça pourrait être une idée… À voir comment un dd de machine RAID pourrait se restaurer dans une éventuelle autre config…

      • [^] # Re: méthode brute ?

        Posté par  . Évalué à 4.

        par contre pas le nombre de hardlinks !

        Et c'est juste l'une des causes de ton problème !

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

        • [^] # Re: méthode brute ?

          Posté par  . Évalué à 1. Dernière modification le 25 juillet 2016 à 16:03.

          Certes, c'est possible (en tout cas c'est ce que j'imagine)… Mais c'est aussi un de mes buts (sécuriser les données).

      • [^] # Re: méthode brute ?

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

        Ma réponse est plutôt oui. Je hais de perdre des données, notamment parce que j’en ai déjà perdues (trop).

        Programmer leur perte n’est pas vraiment la solution à mon problème : je cherche à sécuriser ma sauvegarde ! Voilà pourquoi je ne pratique volontairement pas non plus le « pruning »…

        Ouais mais justement ce n'est pas de la sauvegarde mais de l'archivage.

        Stocker du bordel dont tu n'as plus aucune idée qu'il existe ça ne s'appelle pas sécuriser. C'est plutôt le contraire puisque manifestement ça t'empêche de dupliquer et sécuriser ce qui est vraiment important. Tu es atteint de syllogomanie avec tes données

        Bref, faire des backups incrémentaux pour ne pas perdre x semaines avant ça a du sens. Mais à un moment donné il faut faire le tri entre ce qui est du backup et ce qui est à archiver.

        C'est un peu comme quand tu déménages (ça me connait à 36 ans j'ai déménagé 10x), à chaque fois que tu ouvres tes tiroirs, tes vieilles armoires ou ta cave pour faire tes cartons tu réalises que tu possédais x trucs dont t'avais complètement oublié l'existence ou qui servaient tellement peu que c'est de la pure vanité que de les garder. Leur perte n'a aucune importance puisque tu ne t'en serais pas rendu compte, donc tu peux les jeter/vendre/donner.

        Bref gardes ce qui a vraiment un intérêt à être gardé. Tu te rendras compte que tu le sécuriseras bien mieux.

        • [^] # Re: méthode brute ?

          Posté par  . Évalué à 0.

          Son gros problème c'est que ce ne sont pas ses données. Du coup impossible de savoir ce qui est vraiment important.

          Il lui faudrait éduquer un tout petit peu ses utilisateurs en leur disant "si c'est pas dans ce dossier ça disparaît" après deux pertes de documents "retaper un CV pour la 3eme fois" la consigne est retenue.

          Je trolle dès quand ça parle business, sécurité et sciences sociales

          • [^] # Re: méthode brute ?

            Posté par  . Évalué à 2.

            Il lui faudrait éduquer un tout petit peu ses utilisateurs en leur disant "si c'est pas dans ce dossier ça disparaît" après deux pertes de documents "retaper un CV pour la 3eme fois" la consigne est retenue.

            Tu as peut-être raison, mais j’espère que non :-) J’espère que je pourrais trouver une solution logicielle qui corresponde au besoin de ces utilisateurs et non faire correspondre les utilisateurs à la solution logicielle (cf. https://linuxfr.org/users/beurt/journaux/mon-backup-de-backup#comment-1666807).

            • [^] # Re: méthode brute ?

              Posté par  . Évalué à 2.

              Quand tes utilisateurs agissent de façon débile, ce n'est pas à l'outil de devenir débile et d'accompagner l'utilisateur dans sa débilité.

              Que se passe-t-il lorsque quelqu'un se retrouve avec une armoire pleine à craquer de choses inutiles ? S'il veut s'y retrouver il faut bien qu'il fasse du tri et qu'il se débarasse de ses vieux trucs. Un disque dur c'est pareil. On a jamais pu inventer une armoire qui peut contenir à l'infini tutes les saletés de tout le monde. Ben pour les données informatique c'est la même chose.

        • [^] # Re: méthode brute ?

          Posté par  . Évalué à 0.

          J’ai déjà fait quelques réponses similaires dans ce fil : https://linuxfr.org/users/beurt/journaux/mon-backup-de-backup#comment-1666770

          La différenciation sauvegarde/archivage est super saine… Mais elle ne résiste pas à l’UX des personnes pour lesquelles je fais cette sauvegarde. Pour elles, le tri entre le bon grain et l’ivraie que tu suggères n’est pas vraiment possible (ou pertinent). Ainsi, elles ne le feront pas elles-mêmes. Je ne peux pas le faire automatiquement moi-même. Le « pruning » que tu suggères est bien la seule solution automatique pour avoir le moins mauvais résultat.

          Mais, je le considère encore trop mauvais. Je dis ça d’expérience puisque dans les cas d’utilisation de ce backup il y a plusieurs cas avec récupération de données assez anciennes.

          Comme j’explique aussi dans un autre fil (https://linuxfr.org/users/beurt/journaux/mon-backup-de-backup#comment-1666771), il serait pourrait bien que je finisse par faire une sorte de « pruning » juste au moment de la sauvegarde externe : c’est-à-dire que je ne sauvegarde sur des disques externes que les données depuis une certaine date, par exemple depuis 1 an (moins sûr qu’un vrai « pruning » qui élimine plutôt des snapshots intermédiaires, mais techniquement plus simple). Néanmoins, je trouve ça dommage… C’est pourquoi j’explore pour savoir si d’autres solutions existent (et il y en a si l’on en croit justement le fil susnommé).

          • [^] # Re: méthode brute ?

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

            Backups quotidiens, hebdomadaires, mensuels et annuels (ou semestriels). T'as souvent des demandes de gens qui réclament un fichier qu'ils sont sûrs d'avoir eu sur leur poste entre le 3 janvier et le 26 mars 2013 ?

            Tu comptes garder combien de temps leur backups ? 5 ans ? 10 ans ? l'éternité ?

            À moins que tes moyens soient illimités (ce dont je doute vu le nas tout pourri que tu utilises) à un moment donné tu es obligé de prendre en compte la technique pour définir un service de sauvegarde fiable, notemment la rétention des données sauvegardées et pas le contraire.

            Pour info, nous gérons les backups pour une entreprise de plus de 20000 employés et ceux-ci n'ont de sauvegarde que sur les fichiers qu'ils posent sur les NAS dont la rétention garantie n'est que de 3 mois. Les besoins d'archivages sont traités différemment (les mails par exemple sont archivés). Tout est question de qui signe quoi et de responsabilisation des utilisateurs. Mais il vaut mieux assurer un service de sauvegarde fiable (donc redondant) avec une rétention limitée qu'un service de sauvegarde illimité boiteux lié à la durée de vie de ton unique NAS.

            • [^] # Re: méthode brute ?

              Posté par  . Évalué à 1.

              Backups quotidiens, hebdomadaires, mensuels et annuels (ou semestriels). T'as souvent des demandes de gens qui réclament un fichier qu'ils sont sûrs d'avoir eu sur leur poste entre le 3 janvier et le 26 mars 2013 ?

              La caricature ne m’avance pas beaucoup. Je te donne donc un exemple réel d’utilisation de l’historique du backup. J’avais perdu un document texte (sans doute un effacement un peu agressif de fichiers un jour sans m’en rendre compte). En revenant loin dans l’historique j’ai retrouvé une ancienne version du document texte, puis en avançant dans le temps de l’historique j’ai pu trouver la dernière version du fichier enregistré (et d’ailleurs, par la même occasion, la date de l’effacement fautif et en faisant un diff j’ai pu déterminer qu’il y a avait eu d’autres fichiers que je n’aurais pas dû effacer et les récupérer).

              Tu comptes garder combien de temps leur backups ? 5 ans ? 10 ans ? l'éternité ?

              Tant que j’ai la place, c’est ça le plan.

              À moins que tes moyens soient illimités (ce dont je doute vu le nas tout pourri que tu utilises) à un moment donné tu es obligé de prendre en compte la technique pour définir un service de sauvegarde fiable, notemment la rétention des données sauvegardées et pas le contraire.

              Il ne faut pas exagérer, je prends en compte la technique et des solutions existent. Les posts plus bas le montrent. À mes yeux, le but de la technique c’est de nous servir, pas l’inverse. Certes, il faudra peut-être que je fasse des concessions à la technique, mais pour l’instant, je n’ai pas vraiment eu à le faire et j’aimerais explorer des solutions qui m’évitent d’avoir à le faire.

              Ainsi, j’ai plusieurs pistes intéressantes :

              • des nouvelles comme :
                • dd
                • revenir vers cp -a qui est peut-être suffisant ? (mais qui me pose des soucis à cause de la structure de la sauvegarde : je devrais sans doute combiner avec btrfs pour dédupliquer entre les répertoires à copier)
              • celles que j’envisageais déjà dans le journal :
                • faire un « pruning » lors de la sauvegarde externe en privilégiant les fichiers les plus récents
                • utiliser ZFS ou BTRFS

              • [^] # Re: méthode brute ?

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

                Tant que j’ai la place, c’est ça le plan.

                C'est vague.

                Les posts plus bas le montrent. À mes yeux, le but de la technique c’est de nous servir, pas l’inverse. Certes, il faudra peut-être que je fasse des concessions à la technique, mais pour l’instant, je n’ai pas vraiment eu à le faire

                Manifestement oui puisque tu n'as pas vraiment assuré tes arrières en cas de défaillance de ton NAS, ni l'isolation de tes données : tu fais quoi si un ransomware se retrouve sur un des clients backupés et va chiffrer tes 6 ans de backup ? Bon vu la perf tu t'en rendras compte avant qu'il ait pu chiffrer les 2TB mais bon.

                Si ton NAS le supporte, ZFS peut être une solution intéressante, notemment car il permet de faire des envois de snapshots. Au lieu de faire des hardlinks tu pourrais imaginer créer un snapshot incrémental par jour et un snapshot normal hebdomadaire ou mensuel. Tu pourrais ensuite envoyer régulièrement ces snapshots via la commande zfs send sur une ressource externe de ton choix (sans forcément faire un zfs receive) avant de supprimer ceux-ci sur le nas de backup. L'idée serait que la récupération des données ne serait pas immédiates pour les vieilles données mais il faut s'assurer dans ce cas d'avoir toujours de l'espace sur ton nas pour pouvoir recevoir un ancien snap.

                • [^] # Re: méthode brute ?

                  Posté par  . Évalué à 1.

                  Si ton NAS le supporte, ZFS peut être une solution intéressante, notemment car il permet de faire des envois de snapshots. Au lieu de faire des hardlinks tu pourrais imaginer créer un snapshot incrémental par jour et un snapshot normal hebdomadaire ou mensuel. Tu pourrais ensuite envoyer régulièrement ces snapshots via la commande zfs send sur une ressource externe de ton choix (sans forcément faire un zfs receive) avant de supprimer ceux-ci sur le nas de backup. L'idée serait que la récupération des données ne serait pas immédiates pour les vieilles données mais il faut s'assurer dans ce cas d'avoir toujours de l'espace sur ton nas pour pouvoir recevoir un ancien snap.

                  Le(s) NAS ne supporte pas ZFS nativement… mais c'est quand même quelque chose que je vais explorer dès que possible… Merci pour ces détails de mise en œuvre possible.
                  (mon souci principal reste la conservation de l'existant…)

                  • [^] # Re: méthode brute ?

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

                    Pour la conservation de l'existant et avoir une double des x années actuellement stockées j'aurais tendance à suggérer de démonter les filesystems et faire des dumpe2fs / xfsdump vers un disque attaché au NAS en local.

                    Si tu lances la copie un vendredi soir après les derniers backups des clients d'après mon expérience en local ta copie devrait pouvoir se faire dans un week-end. À voir ce que ça donne avec autant de hard links.

                    Pour la suite des synchronisations via le réseau seront possibles.

              • [^] # Re: méthode brute ?

                Posté par  . Évalué à 5.

                En revenant loin dans l’historique

                « loin » c'est combien ?

                En revenant loin dans l’historique j’ai retrouvé une ancienne version du document texte, puis en avançant dans le temps de l’historique j’ai pu trouver la dernière version du fichier enregistré (et d’ailleurs, par la même occasion, la date de l’effacement fautif et en faisant un diff j’ai pu déterminer qu’il y a avait eu d’autres fichiers que je n’aurais pas dû effacer et les récupérer).

                Tu as besoin de la toute dernière version ? Avec quel granularité ? Là tu peux perdre quelques heures de travail. Est-ce que tu peux te permettre de perdre des jours ?

                Ce n'est même pas une question de technique. L'analyse détaillée des besoins permet de rendre un service de meilleur qualité. Avoir un historique complet et peut être moins intéressant qu'avoir un accès rapide à ces données par exemple.

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

          • [^] # Re: méthode brute ?

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 26 juillet 2016 à 10:06.

            La différenciation sauvegarde/archivage est super saine… Mais elle ne résiste pas à l’UX des personnes pour lesquelles je fais cette sauvegarde.

            C'est parce qu'ils n'ont pas compris la différence.
            C'est très courant, les utilisateurs (même scientifiques) ne voient pas, ne veulent pas voir, le "côté informatique". Et perso je ne leur jette pas la pierre puisque mon expérience fait que je vois des architecctes qui eux mêmes n'ont aucune conscience des outils et organisation qu'ils inventent, aujourd'hui des gens sont propulsés architectes sans aucune expérience technique de terrain. Bon revenons à nos moutons, ce n'est pas le sujet, il s'agissait juste d'illustrer le fait qu'il est difficile de reprocher quoi que ce soit aux utilisateurs lorsque nos propres collègues ne comprennent pas les enjeux techniques et financiers de leur solutions. Ajoutons à cela bon nombre de gens du métier qui voudraient faire comprendre les tenants et aboutissants de chaque contrainte et solution technique à leurs utilisateurs. Au final, c'est pas gagné :)

            Pour faire comprendre il faut illustrer. Pour illustrer il faut des chiffres. Pour faire parler des chiffres il faut parler du besoin. Pour faire parler les utilisateurs de leur besoin il faut poser les bases et leur donner les bons outils d'expression :
            a) retour en service
            b) quantité
            c) durée de conservation

            Ça a l'air con comme ça, mais c'est bien le centre de la question : exprimer les contraintes techniques pour ajuster la réponse au besoin. Lorsqu'on annonce clairement que le temps de restauration sera de cinq jours, il faut bien que les utilisateurs comprennent que c'est cinq jours de service sans données disponibles … Et ça, en général, ils comprennent bien.

            Cela permet de poser ensemble le problème mais selon leur vision à eux, qui est générale binaire :
            La donnée qui doit être disponible le plus vite possible en cas de restauration.
            La donnée qui n'est pas indispensable à un retour rapide de service.

            Voilà, on a nos deux ensembles, les deux seuls réellement indispensables. Tout le reste, dessous, c'est du métier, de la tambouille interne.

            Au final je dirais bien humblement qu'il faut distinguer non pas deux mais trois différences. Pas seulement la distinction sauvegarde / archivage, mais des différences en terme de date : retour rapide / restauration partielle / restauration complète.

            il y a plusieurs cas avec récupération de données assez anciennes.

            C'est (je trouve aussi, toujours amha) le second point, une fois le premier correctement posé et expliqué. C'est la date limite de conservation du produit, au delà de laquelle il sera périmé. Et cela permet d'illustrer parfaitement la différence en terme de temps à retour de service.

            Au final, cela fait un tableau de ce genre :
            les temps à retour attendu de services (retour rapide / restauration partielle / restauration complète)
            les estimations de poids nécessaires à ces services.

            elles ne le feront pas elles-mêmes

            Non, car ce n'est ni leur job ni une nécessité pour eux.
            Par contre la gestion de l'archivage est de leur responsabilité. Au final ils doivent faire deux choses :
            Désigner initialement ce qui sera sauvegardé (à faire une seule fois au début, puis rarement en cas de modif).
            Et gérer ce qui devra être archivé (à faire de manière régulière)
            On ne bascule pas une sauvegarde en archive, et on ne sert pas d'un archivage pour des sauvegardes. Les seules personnes à même de savoir ce qui doit être archivé ce sont les utilisateurs. Qu'ils dérapent et que ça ne soit pas parfait n'est pas ton problème, et rien n'est jamais parfait. La sauvegarde c'est toi, l'archivage tu te contente de leur fournir de l'espace et un outil.

            tl;dr, un peu blabla, désolé.
            et on va laisser de côté le vocabulaire bingoloto du genre "dé-duplication / ré-hydratation de la donnée" …

            • [^] # Re: méthode brute ?

              Posté par  . Évalué à 2.

              Merci pour ces détails qui pourront être utiles à certains.

              En ce qui me concerne, je suis parfaitement au courant de ces subtilités. Je ne cherche pas à mettre en place ce type de dispositif. Je cherche au contraire à être dans un environnement peu contraint pour les utilisateurs. En premier lieu parce que, comme tu l’écris, la contrainte a déjà été tentée et qu’elle ne fonctionne pas du tout. Quels que soient les arguments avancés. Cette distinction sauvegarde/archivage, c’est une distinction de technicien. Ceux dont je fais la sauvegarde ne peuvent ni ne veulent faire cette distinction (c’est d’ailleurs ce que tu expliques).
              À priori, ils préfèrent même ne pas avoir de sauvegarde plutôt que de se casser les pieds avec des machins pareils… sauf le jour où ils se rendent compte qu’ils ont perdu des données : là ils veulent une sauvegarde, là ils sont pour la discipline, le rangement, etc. Ça dure 3 semaines à 3 mois et puis on oublie jusqu’à la prochaine catastrophe.

              Les gens ont effectivement d’autres choses à faire qu’à être vigilants sur leurs assurances. On a des automates, autant les utiliser pour alléger l’attention des humains sur ces aspects dans lesquels ils sont peu efficaces et pour lesquels ils ont peu d’appétit.

              C’est ce que j’essaie de faire. Je suis conscient que le défi n’est pas élémentaire à résoudre (et en plus moi aussi j’ai très peu de temps à y consacrer).

              Mais grâce à ce journal, plusieurs solutions qui semblent viables émergent déjà (en particulier dans ce fil : https://linuxfr.org/users/beurt/journaux/mon-backup-de-backup#comment-1666771)

              • [^] # Re: méthode brute ?

                Posté par  (Mastodon) . Évalué à 8. Dernière modification le 26 juillet 2016 à 11:15.

                Cette distinction sauvegarde/archivage, c’est une distinction de technicien

                Non. Vraiment pas.
                Seul l'utilisateur connait sa donnée. C'est le seul en mesure de savoir ce qui doit être archivé.
                L'archive relève donc entièrement de la responsabilité de l'utilisateur.
                Nous sommes là dans un sujet de conservation et de pérennisation de patrimoine. Ici l'informatique n'intervient que pour mettre à disposition de l'espace et un outil. L'outil d'archivage doit être manipulé par les utilisateurs exclusivement.

                Pour la sauvegarde, l'informatique intervient à tout les niveaux : donner le service dans des contraintes mutuellement comprises d'espace et de temps, rendre le service selon les contraintes mutuellement définies (& avoir à disposition de l'espace et de l'outillage.)

                Le fait d'avoir du mal à distinguer ce qui doit être archivé de ce qui doit être sauvegardé et de ce qui ne doit pas l'être est un problème humain, et pas technique. Ce problème est certes commun et partagé par le technicien et l'usager, oui :-)) Mais cela n'en fait pas une raison pour que l'usager délègue la responsabilité du choix de ce qui doit être archivé au technicien.

                C'est vraiment primordial cette histoire.
                Les sauvegardes sont décidées initialement par l'usager. Puis le service est rendu par le technicien informatique.
                L'archivage doit être maintenu par l'utilisateur.

                Si tu n'as pas ce problème, alors tu n'as pas de question d'archivage. Tu as juste un problème de dates à tes sauvegardes ;-)

              • [^] # Re: méthode brute ?

                Posté par  . Évalué à 2.

                Cette distinction sauvegarde/archivage, c’est une distinction de technicien.

                C'est comme si tu disais que le choix du plat que tu veux manger au restau (entrée/plat/dessert, choix dans le menu) était une distinction de cuisinier.

                C'est comme si tu disais que le choix de vêtement que tu vas mettre pour aller au travail est une distinction de couturier, ou de vendeur de vêtement.

                Le cuisinier ne connait pas tes gouts et tes besoins. Il te propose son savoir-faire pour te préparer à manger. En aucun cas il ne peut connître tes gouts ou tes besoins en terme de nourriture. Idem pour le couturier, ou le vendeur de vêtements : il ne peut pas savoir dans quelles circonstances tu vas utiliser les vêtements, c'est à toi de le déterminer et de les acheter en conséquences. Ben pour la sauvegarde/archivage c'est la même chose : tu ne peux que proposer des solutions, et c'est à l'utilisateur de choisir la solution adaptée à son besoin.

                • [^] # Re: méthode brute ?

                  Posté par  . Évalué à 1.

                  Je n’adhère pas à tes métaphores qui ne me semblent pas appropriées. Ici, on a des utilisateurs qui veulent « conserver » (longtemps) leurs contenus. Ils veulent savoir que s’ils en ont besoin, ces contenus seront là. Les distinctions plus fines sont (hélas ! je le sais d’expérience) assez inopérantes : comme je l’expliquais plus haut, on se retrouve dans une situation de conservation encore moins sûre que si on ne leur demande pas de faire de distinction.

                  Mais, j’ai l’impression que ces questions nous ramènent au débat (obsolète à mes yeux) sur la pertinence de la conception centrée utilisateur. Et du coup, c’est un peu hors sujet…

                  En attendant, le second cp (~60 % des contenus) se poursuit…

                  • [^] # Re: méthode brute ?

                    Posté par  . Évalué à 2.

                    Ben dans mes métaphores, on a des personnes qui veulent manger à leur faim ou des personnes qui veulent s'habiller. On pourrait aussi utiliser la métaphore d'un architecte à qui tu demandes de te construire une maison ou tu pourrais dormir et t'abriter sans lui préciser plus ton besoin.

                    Mais, j’ai l’impression que ces questions nous ramènent au débat (obsolète à mes yeux) sur la pertinence de la conception centrée utilisateur.

                    N'importe quoi. Tant que les utilisateurs n'auront pas compris qu'ils ont leurs choix à faire, et que la technique n'est pas là pour prendre les décisions à leur place, on n'avancera pas.

                    • [^] # Re: méthode brute ?

                      Posté par  . Évalué à 1.

                      Mais, j’ai l’impression que ces questions nous ramènent au débat (obsolète à mes yeux) sur la pertinence de la conception centrée utilisateur.
                      N'importe quoi. Tant que les utilisateurs n'auront pas compris qu'ils ont leurs choix à faire, et que la technique n'est pas là pour prendre les décisions à leur place, on n'avancera pas.

                      Gnii ? Comment ça « n’importe quoi » ? Qu’est-ce qui est n’importe quoi ? Ce que tu viens d’écrire me semble confirmer ce que je dis. Tu n’es pas dans la perspective de la conception centrée utilisateur : il faut partir des besoins et contraintes des utilisateurs et la technique doit s’adapter. À mon avis, c’est ça le but de la conception centrée utilisateur.

                      Dit autrement, il me semble que l’idéal est : Ce n’est pas à eux de comprendre ce que le concepteur/développeur veut et a comme contraintes avec sa technologie, c’est à lui de faire en sorte que sa technologie réponde à leur besoin.

                      • [^] # Re: méthode brute ?

                        Posté par  . Évalué à 2.

                        il faut partir des besoins et contraintes des utilisateurs et la technique doit s’adapter

                        ben oui, mais c'est pas à la technique de définir le besoin : elle ne fait que fournir des solutions. Tout comme ce n'est pas au cuisinier de définir ce que t veux manger : il ne fait que proposer des plats. Si tu ne veux pas de sel dans ton plat (pour raison médicale par exemple) il n'a pas à le deviner, c'est toi qui doit lui dire.

                        J'arrête là la discussion. J'en ai assez de ces gens qui assimilent la technique à de la magie qui doit tout pouvoir faire à leur place. Ca va m'agacer de continuer.

                        • [^] # Re: méthode brute ?

                          Posté par  . Évalué à 1.

                          La technique n’est certainement pas de la magie. Il n’en reste pas moins qu’elle est au service du projet des humains, non l’inverse (enfin… jusqu’à Skynet, après on verra…)

  • # Hum ?

    Posté par  . Évalué à 7. Dernière modification le 25 juillet 2016 à 14:45.

    Tes problèmes de liens symboliques me donnent l'impression que tu ne fais que du backup incrémentale (ou décrémental). C'est vraiment le cas ? Tu as vraiment besoin de garder 6 ans d'historique quotidiens ? Généralement la fréquences des archives diminue avec l'age (quotidien sur la dernière semaine, hebdomadaire sur l'année, mensuel ensuite par exemple avec des durée de rétention limité) ce qui permet de gagner BEAUCOUP de place.

    Ton backup pourrait du coup être la copie tel quel d'une archive complète (pas d'un incrément). Du coup du n'a pas de lien à gérer (enfin pas plus que ce qu'il y a actuellement sur ta machine). Le processus complet serait alors :

    • tu fais un backup incrémental/décrémental quotidien sur ton NAS
    • (si tu fais de l'incrémental) tu fais un backup complet hebdomadaire et on supprime les incréments d'il y a quelques semaines/mois
    • tu fais une copie de ce backup sur ton second NAS

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

    • [^] # Re: Hum ?

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

      Et même.

      Il a 2To de bordel. Si il fait un "cp -a" il copie son bordel et ça fera… 2To !
      Un disque de 3To ou 4To pour voir large, il fait périodiquement son cp -a (en écrasant la précédente et en vivant sans backup de backup pendant 1 nuit, le temps que le "cp -a" s'exécute).

      Je vois pas trop où est le soucis en fait.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Hum ?

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

        Le problème c'est que "cp -a" et des millions de hardlinks ca fait pas bon ménage. Cf le lien que j'ai posté dans un fil de discussion ci-dessus ;)

        Le vrai pb ici c'est que gérer des millions de hardlinks c'est problématique pour la plupart des outils courants (rsync s'en sort pas mieux).

    • [^] # Re: Hum ?

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

      Généralement la fréquences des archives diminue avec l'age (quotidien sur la dernière semaine, hebdomadaire sur l'année, mensuel ensuite par exemple avec des durée de rétention limité) ce qui permet de gagner BEAUCOUP de place.

      D'ailleurs, c'est le but même des outils comme Bacula.

    • [^] # Re: Hum ?

      Posté par  . Évalué à 0.

      Tes problèmes de liens symboliques me donnent l'impression que tu ne fais que du backup incrémentale (ou décrémental). C'est vraiment le cas ? Tu as vraiment besoin de garder 6 ans d'historique quotidiens ? Généralement la fréquences des archives diminue avec l'age (quotidien sur la dernière semaine, hebdomadaire sur l'année, mensuel ensuite par exemple avec des durée de rétention limité) ce qui permet de gagner BEAUCOUP de place.

      Le problème ne vient pas des liens symboliques, mais des hardlinks.

      Oui, je veux garder mes vieilles infos, c’est pour ça que j’en fais la sauvegarde. Le « pruning » ne me ferait pas gagner tant de place que ça, seulement diminuer le nombre de hardlinks.

      Pour reprendre : j’ai un backup incrémental de plusieurs machines sur un NAS (donc qui dit incrémental, dit hardlinks). Je veux sécuriser ce backup → copie du contenu du NAS ailleurs. Mais comme au total ça fait des paquets de To, je veux conserver les hardlinks.

      tu fais une copie de ce backup sur ton second NAS

      C’est exactement ce que je tente de faire : une copie, non incrémentale, de données comprenant de très très nombreux hardlinks.

      • [^] # Re: Hum ?

        Posté par  . Évalué à 7.

        Le problème ne vient pas des liens symboliques, mais des hardlinks.

        C'était un lapsus.

        Le problème ne vient pas des liens symboliques, mais des hardlinks.

        Oui, je veux garder mes vieilles infos, c’est pour ça que j’en fais la sauvegarde. Le « pruning » ne me ferait pas gagner tant de place que ça, seulement diminuer le nombre de hardlinks.

        Ça me paraît donc déjà pas mal diminuer leur nombre.

        Oui, je veux garder mes vieilles infos, c’est pour ça que j’en fais la sauvegarde.

        La question c'est as-tu besoin d'une granularité à la journée ? Est-ce que tu pense sincèrement avoir besoin d'un fichier que tu a créé le 3 avril 2011 et supprimé le 5 ? La gestion de la données ce n'est pas tout garder pour tout garder, c'est de savoir discriminer ce qui est important de ce qui ne l'est pas (car plus on réduit le nombre de fichiers, leur volume, le nombre de lien, etc plus les actions seront facile - c'est justement ton problème -).

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

        • [^] # Re: Hum ?

          Posté par  . Évalué à 3.

          Comme beaucoup, je pense que l'objectif premier c'est d'avoir une bonne sauvegarde, à plusieurs endroits. Je comprends que c'est un souhait d'avoir un historique, mais de ce que je vois tu as actuellement :
          - Tes données
          - Une sauvegarde sur NAS, au même endroit

          S'il y a un incendie, un dégât des eaux ou un vol, on peut présumer que tu risque de tout perdre :(

          L'objectif dans un premier temps c'est d'avoir la possibilité de restaurer tes données en cas de coup dur, donc essaye surtout d'avoir une copie de tes données (même sans historique), dans plusieurs endroits éloignés.

          « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Hum ?

            Posté par  . Évalué à 0.

            Oui, mon but est la sécurisation…

            Et oui, pour l'instant j'ai un problème de sécurisation physique que j'essaie justement de résoudre par le backup sur disque externe.

            Mais j'ai du mal à me résoudre au « pruning »… Pour moi c'est une sorte d'échec de ma solution de sauvegarde…

            C'est pourquoi j'envisage une sorte de « pruning » light qui consiste à ne sauvegarder que les fichiers les moins anciens (idées : https://coolaj86.com/articles/how-to-rsync-files-by-date-or-by-size.html) sur le disque externe (c'est la solution que je présente dans le journal)…

            • [^] # Re: Hum ?

              Posté par  . Évalué à 6.

              C'est pourquoi j'envisage une sorte de « pruning » light qui consiste à ne sauvegarder que les fichiers les moins anciens (idées : https://coolaj86.com/articles/how-to-rsync-files-by-date-or-by-size.html) sur le disque externe (c'est la solution que je présente dans le journal)…

              C'est bizarre. Pourquoi passer par des étapes chelous plutôt que directement utiliser les pratiques éprouvées en réfléchissant de manière posé à la rétention de tes données ?

              Personnellement je traite de manière différentes :

              • des données dont je veux tout garder (historique complet) : git
              • des données que je ne veux pas perdre là tout de suite mais dont la durée de vie est faible : synchronisation sur plusieurs machines
              • des données du genre immuables dont la durée de vie est « infinie » (les photos par exemple) : archivage très simple sur 2 autres disques durs externe sur les quels je ne fais que des ajouts

              Pour mon besoin, je n'ai pas besoin de plus.

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

              • [^] # Re: Hum ?

                Posté par  . Évalué à 0.

                Oui, c'est sûr qu'on pourrait être mieux organisé avec les données. C'est ce que j'essaie de faire avec les miennes.
                Mais, la vie est parfois un peu plus complexe que dans le schéma idéal. Et là ce qui est complexe c'est que je ne sauvegarde pas que ma machine. Et je ne peux pas faire raisonner comme ça les autres sur leurs machines (qui sont toutes en bordel). En bref, backintime leur sauvegarde toutes leurs données (sauf les dépôts SVN/GIT, les binaire et notamment les jeux, et autres bricoles comme les VM qui sont exclues).

                Le problème bien évoqué par zurvan est la sécurité de ce backup. Le RAID 6 c'est déjà pas mal, mais pas suffisant. Voilà pourquoi j'essaie maintenant de sécuriser tout ça sur des disques externes. Il serait très complexe d'automatiser un tri (compte tenu de la variété des façon de ranger ce qui est sauvegardé). Le seul tri qui est (moyennement) pertinent c'est le « pruning »… si on l'accepte…

                • [^] # Re: Hum ?

                  Posté par  . Évalué à 10.

                  Le problème bien évoqué par zurvan est la sécurité de ce backup. Le RAID 6 c'est déjà pas mal

                  Non. Définitivement NON. Le RAID n'est pas fait pour assurer la sauvegarde mais la DISPONIBILITE !!! Le jour ou vous perdrez vos données parce que vous n'avez pas su faire la différence, faudra pas pleurer.

                  • [^] # Re: Hum ?

                    Posté par  . Évalué à 1.

                    Je m'attendais à une réaction comme la tienne plus tôt. Donc ma réponse toute prête est en deux temps :
                    1. j'essaie justement de faire une sauvegarde plus durable de ces données.
                    2. ce NAS contient une copie des données (et non un stockage) qui est relativement plus sûre (compte tenu qu'il faut que 2 disques sur 5 foirent en même temps) que si c'était sur un seul disque.

                    Revenons au sujet: comment rendre plus sûre cette première sauvegarde ?

                    • [^] # Re: Hum ?

                      Posté par  . Évalué à 4. Dernière modification le 25 juillet 2016 à 20:05.

                      Revenons au sujet:

                      Mais c'est le sujet : tu confonds tout (sauvegarde, archivage, disponibilité) et c'est pour ça que tu ne trouves pas la solution.

                      Sinon, j'ai peut-être une solution mais faut que je relise tes posts por être sur.Si je ne reviens pas dessus, c'est que je me suis trompé.

                      • [^] # Re: Hum ?

                        Posté par  . Évalué à 3.

                        Merci pour la recherche d’une solution…

                        je te rajoute un post à lire :

                        Comme je l’écrivais en réponse à barmic (juste avant ta réponse), on ne fait pas toujours ce qu’on veut. Je dois sauvegarder les données de plusieurs machines (genre cadre familial), et ce de façon fiable.

                        J’utilise donc backintime sur un NAS en RAID 6. C’est bien : ça a permis plusieurs fois à ceux qui perdent leurs données de les retrouver (et c’est arrivé plus de fois que je ne les compte depuis que le truc est en place).

                        Cependant, le RAID 6 n’étant pas, comme tu le signales gentiment :-), parfait je voudrais sécuriser cette sauvegarde. Donc, faire une sauvegarde externe.

                        Tu dis que je confonds tout et moi je te réponds tu distingues des choses qui ne résistent pas à l’expérience utilisateur : sauvegarde, archivage ? Pour eux, l’important c’est que leurs données soient conservées toutes seules. C’est ce que j’essaie de faire. Pour info, oui, j’ai déjà essayé de leur faire ranger les trucs à archiver dans un répertoire donné : ça ne fonctionne pas (ils oublient, et les trucs importants sont finalement toujours là où il ne faut pas).

                        Peut-être que je pêche par manque de rigidité, mais il se trouve que mon expérience dans le monde du logiciel me fait penser que les solutions qui imposent à l’utilisateur des méthodes différentes des leurs donnent de très mauvais résultats. Ainsi, je crois et je soutiens activement les logiciels qui s’adaptent aux utilisateurs (plutôt que l’inverse donc…). Dans ce cas précis : j’ai des gens qui foutent le boxon dans leurs ordis et qui ont besoin d’une sauvegarde. J’essaie de leur donner, sans les forcer à ranger le boxon qu’ils n’arrivent ou ne veulent pas ranger (et pour eux, c’est déjà rangé, d’ailleurs).

                        • [^] # Re: Hum ?

                          Posté par  . Évalué à 7.

                          Comme je l’écrivais en réponse à barmic (juste avant ta réponse), on ne fait pas toujours ce qu’on veut. Je dois sauvegarder les données de plusieurs machines (genre cadre familial), et ce de façon fiable.

                          Ce que je n'arrive pas à comprendre, c'est comment un utilisateur peut avoir besoin d'un historique aussi détaillé. Qui se souvient d'un fichier créé et supprimé en l'espace de quelques jours il y a plus de 5 ans ? T'es utilisateurs naviguent régulièrement dans des leurs archives quotidiennes d'il y a 3 ans ?

                          Je ne dis pas qu'il faut tout supprimer, juste que garder une granularité quotidienne sur 10 ans, je ne comprends pas comment ça peut être utile.

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

      • [^] # Re: Hum ?

        Posté par  . Évalué à 6. Dernière modification le 25 juillet 2016 à 16:04.

        Tu as pensé à btrfs ? btrfs send est supposé prendre en compte les hardlinks.

        Un test à l’arrache me le confirme :

        btrfs subvolume create test
echo hello > test/1
ln test/1 test/2
btrfs subvolume snapshot -r test test-ro
btrfs send test-ro | strings

        Me donne bien une unique occurrence de "hello" dans le backup.

      • [^] # Re: Hum ?

        Posté par  . Évalué à 6.

        Mes 2 cents:
        - vouloir garder l'historique ad-vitam avec des hard-link n'est pas possible car il y a une limitation du nombre de liens par inode.
        - utilise un filesystem qui est prévu pour cet usage (c.-à-d. qui peut faire des snapshots): en libre il y a ZFS et HAMMER (BTRFS a une mauvaise réputation). Il y a aussi une limitation sur le nombre de snapshot, néanmoins avec les fonctions de réplications tu peux imaginer garder différents snapshots sur différents sites (genre 1/mois sur le backup de backup).
        - ou un système de backup style bacula, là aussi ce genre de truc n'est pas fait pour avoir une DB qui grandi à jamais, à toi de voir.
        - dd pour te dépanner directement, voire xfsdump.

        • [^] # Re: Hum ?

          Posté par  . Évalué à 2.

          en libre il y a ZFS et HAMMER

          Il y a vraiment des gens qui utilisent HAMMER en production ? :)

          • [^] # Re: Hum ?

            Posté par  . Évalué à 2.

            Oui les gens qui l'ont conçu :) Et moi pour mes backups personnels… :p Et tant que ça marche, le facteur "bus" ne me dérange pas.

        • [^] # Re: Hum ?

          Posté par  . Évalué à 0.

          ZFS fait partie des choses que je veux tester… Pas anodin à mettre en œuvre sur un NAS (j'ai l'impression qu'il faut des machines plutôt balaises côté RAM+CPU). Mais c'est prévu…

      • [^] # Re: Hum ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 juillet 2016 à 16:10.

        Question sans doute idiote mais pourquoi des hard links ? Perso, je ne me rappelle pas en avoir créé une seule fois en 20 ans :)
        Dans quel cadre en utilises-tu ?

        • [^] # Re: Hum ?

          Posté par  . Évalué à 1. Dernière modification le 25 juillet 2016 à 16:37.

          Économiser l'espace. Avec des hardlink au maximum tu as une copie de chaque version de chaque fichier. Sans, tu as autant de copie que de versions de ton répertoire.

          • [^] # Re: Hum ?

            Posté par  . Évalué à 4. Dernière modification le 25 juillet 2016 à 17:01.

            Ta formulation ne me semble pas exacte, du moins trompeuse.

            tu as une copie de chaque version de chaque fichier

            Non, les hardlinks ne te permettent pas de revenir en arrière…

            Plusieurs hardlinks sont d’autres noms pour un même fichier. Donc effectivement dans le cadre de backup incrémentaux, si le 12 du mois tu as un fichier 'lefile.txt' dans ton backup, au backup d’après si ce fichier n’a pas été modifié il sera présent directement dans l’arbo du backup suivant via un hardlink. Ça s’arrête là.

            Donc je dirais plutôt : « Tu as une seule copie de chaque fichier ».

            • [^] # Re: Hum ?

              Posté par  . Évalué à 9.

              Le principe de la sauvegarde avec « déduplication » via liens durs est le suivant :
              0 - copie initiale des données vers la sauvegarde
              1 - lors de chaque sauvegarde :
                1.1 - dupliquer le dossier de la dernière sauvegarde en utilisant uniquement des liens durs (par exemple : cp --no-dereference --preserve=links,mode,ownership,timestamps --recursive --link /chemin/sauvegarde_précédente /chemin/sauvegarde_en_cours)
                1.2 - faire un rsync depuis les données à sauvegarder, vers le nouveau dossier de sauvegarde

              Résultat :
              - un fichier qui ne bouge pas n'existe qu'une seule fois dans le système de fichiers
              - un fichier modifié sera remplacé par rsync (inode différent, à condition de ne pas utiliser l'option --inplace). Il reste stocké en un seul exemplaire. S'il vient à être modifié de nouveau, il est re-dupliqué par rsync et le cycle recommence

              Effet de bord :
              - on peut supprimer des sauvegardes intermédiaires sans perdre les données avant/après. Par exemple on peut effacer les sauvegardes datant de plus d'une semaine sauf le dimanche, et effacer celles de plus d'un mois sauf le premier dimanche

              ZFS + rsync + instantanés fonctionne aussi très bien, avec le même effet de bord, mais nécessite plus de mémoire (je fais tourner depuis des années la méthode liens durs + rsync avec un Debian à jour sur un monocœur équipé de 256 Mio de mémoire sans swap. Impossible avec ZFS).

        • [^] # Re: Hum ?

          Posté par  . Évalué à 5.

          C'est juste la déduplication de ses backups.

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

        • [^] # Re: Hum ?

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

          Le hardlink est la botte secrète de la sauvegarde incrémentale par snapshot. Tu connais le Time Capsule de Apple (pas certain du nom) ?

          Voici une très bonne explication pour se l'implémenter avec 2 commandes : rsync et… ah non, une seule commande ;)

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

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Hum ?

            Posté par  . Évalué à 3.

            Ou sinon, comme le cite l'auteur du post, backintime.

          • [^] # Re: Hum ?

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

            Time Capsule est le nom d'un NAS qui peut servir pour TimeMachine.
            TimeMachine utilise bien des hardlinks… mais des hardlinks sur les dossiers ! Le système de fichiers (HFS+) a été modifié pour ça. Forcément, ça change tout ;)

        • [^] # Re: Hum ?

          Posté par  . Évalué à 4. Dernière modification le 25 juillet 2016 à 17:16.

          Question sans doute idiote mais pourquoi des hard links ? Perso, je ne me rappelle pas en avoir créé une seule fois en 20 ans :)
          Dans quel cadre en utilises-tu ?

          En l’occurrence, c'est le logiciel de backup (ici backintime) qui créé les hard links de façon transparente.

  • # Externaliser "sous" le FS

    Posté par  . Évalué à 10.

    J'utilise BackupPC depuis des années, qui a le même problème concernant l'externalisation: la quantité de hardlinks rend la copie "au dessus" du FS quasi impossible (que ce soit rsync, ou cp, ou dump2fs). Deux axes pour externaliser

    • Exporter uniquement le dernier jeux de sauvegarde (ça ne semble pas être ce que tu cherches, mais c'est très souvent plus que suffisant)
    • Faire une copie "sous" le FS

    Pour le deuxième axe, là encore, plusieurs possibilités:

    • Un bon vieux dd de temps en temps. Problème: pas de copie incrémentielle, il faut tout transférer à chaque fois, ça peut être long. Aussi, le FS source doit être figé pendant la copie, donc snapshot LVM obligatoire selon la durée de la copie
    • Une synchro RAID logiciel (c'est ce que j'utilise assez régulièrement): sur ton NAS, il faut stacker 2 couches de RAID: un premier RAID6 comme l'actuel, et de ce RAID6, tu crées au dessus un RAID1 avec un seul membre. Au dessus de ce RAID1, tu y mets ce que tu veux (FS directement ou LVM + FS, ou dmcrypt + LVM + FS, bref….). Ensuite, de temps en temps, tu connectes ton disque externe, tu l'ajoutes au RAID1, il récupère toutes les données, quand la synchro est terminée, tu peux casser le RAID et mettre ce disque en lieux sûr. Il faut par contre impérativement avoir 2 disques externes au minimum, et toujours en avoir un hors site. J'ai un petit script qui permet d'automatiser l'ajout/retrait de disques externes à un RAID logiciel: https://wikit.firewall-services.com/doku.php/tuto/sauvegardes/externalisation_raid1 (c'est pour BackupPC, mais ça peut s'adapter facilement)
    • Une autre possibilité est d'utiliser drbd sous le FS (il faut par contre une autre machine, pas juste un disque externe). drbd est plutôt efficace quand la connexion se rétablie pour ne transférer que les zones modifiées depuis la dernière fois
    • enfin, comme déjà évoqué, les FS modernes type ZFS ou BTRFS avec leur fonctions respectives de send/receive devraient permettre aussi de faire ça (mais j'ai pas d'expérience avec ceux là)

    voilà mes 2ct sur ce sujet ;-)

    • [^] # Re: Externaliser "sous" le FS

      Posté par  . Évalué à 1.

      Ils sont cool tes 2cts !

      Et finalement tu utilises quoi toi ? Je présume la syncho RAID puisque c'est celle que tu détailles le plus. Du coup la restauration d'un tel backup nécessite sans doute de re-créer un RAID 1 similaire ? (mais justement avec quelle similarité ?)

      Tout le monde insiste sur le « pruning » la solution est donc sans doute du côté d'un backup externalisé seulement de la dernière année. C'est sans doute ce que je vais tenter cette année :-) Je viens de lancer un find avec un mtime 365 pour voir (et ça prend bien son temps !)…

      Le dd me plaît bien aussi, mais c'est pareil je me demande dans quelle mesure c'est restaurable facilement (je ne pratique pas dd).

      • [^] # Re: Externaliser "sous" le FS

        Posté par  . Évalué à 6.

        J'utilise plusieurs solutions, parfois combinées selon le niveau de service requis (dans un cadre pro, donc dépend du client, de la bande passante, du volume de données, du budget etc…).

        J'utilise le plus souvent l'externalisation par le RAID1 effectivement. C'est limité à la taille d'un disque (mais on trouve des disques externes de 12To comme les Laci 2Big par exemple). Avec cette technique, il n'y a pas vraiment à restaurer quoi que ce soit. En cas de besoin, il suffit de ré-assembler le RAID depuis le disque externe (mdadm --assemble /dev/md127 /dev/sdb1 par exemple). Si on veux réinjecter les données sur le NAS, il suffit d'assembler le RAID1 depuis le disque externe, puis d'ajouter le RAID6 du NAS en tant que membre, et la synchro se fera dans l'autre sens.

        J'utilise DRBD aussi entre 2 machines d'un DC, pour avoir de la redondance. C'est la solution la plus complexe je trouve.

        Enfin, pour dd, comme pour le RAID, la restauration est très simple: dd te donne une image de ton périphérique block. Tout dépend de la destination de ton dd (tu peux utiliser un autre périphérique block comme destination, ou alors un fichier). Dans tous les cas, il suffit de refaire un dd dans l'autre sens (inversant source et dest) pour "restaurer"

        Aussi, autre option possible (et que j'utilise souvent): un autre serveur de sauvegarde, externalisé. Ton serveur local et le distant sauvegardent tous les deux les mêmes jeux de données, sur des créneaux horaires différents. Le premier transfert sera long, mais les suivants pourront profiter de rsync

        • [^] # Re: Externaliser "sous" le FS

          Posté par  . Évalué à 0.

          Merci pour les conseils précieux !

          J'utilise le plus souvent l'externalisation par le RAID1 effectivement. C'est limité à la taille d'un disque (mais on trouve des disques externes de 12To comme les Laci 2Big par exemple). Avec cette technique, il n'y a pas vraiment à restaurer quoi que ce soit. En cas de besoin, il suffit de ré-assembler le RAID depuis le disque externe (mdadm --assemble /dev/md127 /dev/sdb1 par exemple). Si on veux réinjecter les données sur le NAS, il suffit d'assembler le RAID1 depuis le disque externe, puis d'ajouter le RAID6 du NAS en tant que membre, et la synchro se fera dans l'autre sens.

          Elle me plait cette méthode, mais si je comprends bien il faut une autre machine RAID spécifiquement pour le backup (dans mon cas, changer le RAID du NAS de backup n'est pas envisageable: tous les slots sont occupés, et je ne peux justement pas en faire une sauvegarde facilement), et le backup ne peut être restauré que dans un contexte très proche (avec un « demi » RAID 1 sous la main).

          J'utilise DRBD aussi entre 2 machines d'un DC, pour avoir de la redondance. C'est la solution la plus complexe je trouve.J'utilise DRBD aussi entre 2 machines d'un DC, pour avoir de la redondance. C'est la solution la plus complexe je trouve.

          Ah ? connais pas… je vais regarder… (ça a l'air d'être pour les barbus à poils longs, moi je suis plutôt à poils courts…)

          Enfin, pour dd, comme pour le RAID, la restauration est très simple: dd te donne une image de ton périphérique block. Tout dépend de la destination de ton dd (tu peux utiliser un autre périphérique block comme destination, ou alors un fichier). Dans tous les cas, il suffit de refaire un dd dans l'autre sens (inversant source et dest) pour "restaurer"

          Pour le dd, je vois aussi deux obstacles :

          • j'ai l'impression que la restauration doit se faire sur la même structure de fs (probablement dans un RAID 6, non ?)
          • il me faut trouver des HD de 4 To pas chers (car dans le NAS de backup il y a les backup de backintime avec leurs hardlinks, mais aussi d'autres backups qui font au total 4To).

          Aussi, autre option possible (et que j'utilise souvent): un autre serveur de sauvegarde, externalisé. Ton serveur local et le distant sauvegardent tous les deux les mêmes jeux de données, sur des créneaux horaires différents. Le premier transfert sera long, mais les suivants pourront profiter de rsync

          Ça, j'aime bien ! mais dans mon cas, c'est le premier rsync qui pose souci. D'ailleurs c'est ce que j'envisageais de faire sur mon disque externe quand le premier rsync aurait été terminé : refaire des rsync réguliers quand je les ramène chez moi.

    • [^] # Re: Externaliser "sous" le FS

      Posté par  . Évalué à 7. Dernière modification le 25 juillet 2016 à 18:20.

      Autrement pour bouger le contenu d'un FS utilisé avec backuppc, il y a une astuce en trois étapes :

      1. rsync sur le pool
      2. reconstruire la structure des hardlinks
      3. rsync complet

      Il y a des scripts pour l'étape 2, celle qui justement pose problème à l'auteur du journal. Par exemple ici (version en cache google il semble y avoir des problèmes d'accès sur la page).

      Je ne sais pas si c'est applicable pour le problème initial, car la structure de BackupPC, d'avoir un répertoire avec un hardlink de chaque fichier en plus des hardlink dans toutes les sauvegardes simplifie la tache, mais il y a peut-être moyen de s'en inspirer.

      • [^] # Re: Externaliser "sous" le FS

        Posté par  . Évalué à 2.

        Oui, c'est effectivement une possibilité. Mais c'est spécifique à BackupPC, et c'est pas toujours plus rapide qu'un dd/raidsync (dépend de la vitesse d'accès aléatoires de ton pool de sauvegarde, et du taux d'utilisation du FS). Dans tous les cas, j'ai plus confiance dans une copie bas niveau pour ce genre de schéma de stockage.

        • [^] # Re: Externaliser "sous" le FS

          Posté par  . Évalué à 2.

          Disons que j'ai assez confiance pour ma part, uniquement à cause au rsync final qui s'occupe de corriger ce qui aura potentiellement merdé dans l'étape avec des scripts. Sans le rsync final, j'avoue que ma confiance serait un peu (comprendre beaucoup) plus limitée.

          Après ça dépend du contexte, une fois lors d'une migration du pool, je ne pouvais pas faire une copie bas-niveau, une autre fois je pouvais, et je l'ai fait.

          En passant, tu as essayé tar ? Je ne sais pas comment il gère (car il les gère), les hardlinks, si il garde provisoirement une structure associant les nom aux inodes en RAM comme le fait rsync (ce qui fait exploser le NAS) ou via un autre moyen ? Car si tar fonctionne, après rsync pour les mises-à-jour est envisageable.

          • [^] # Re: Externaliser "sous" le FS

            Posté par  . Évalué à 2.

            Aucune solution (tar, rsync, dump2fs) de haut niveau ne fonctionne quand on fait une utilisation intensive de hardlinks. Rsync demande trop de RAM (moins depuis la v3, mais toujours bcp), tar en demande moins, mais dans tous les cas, ce n'est pas tellement la RAM occupée le pb, mais le temps nécessaire à scanner tout ça, et à recréer la structure sur la destination. Quand le nombre de hardlinks est trop important, la seule solution (v|f)iable est la copie bas niveau

      • [^] # Re: Externaliser "sous" le FS

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

        Pour info, BackupPC 4 n'utilise plus de hardlinks :

        "No use of hardlinks (except temporarily to do atomic renames). Reference counting is handled at the application level in a batch manner."

        http://backuppc.sourceforge.net/BackupPC-4.0.0alpha3_doc.html#BackupPC-4.0

        Ce qui veut dire qu'en théorie, l'OP pourrait l'utiliser tout en conservant un historique avec une granularité très importante (excessive d'après moi aussi) sans être inquiété par une consommation mémoire excessive lors des copies distantes.

        Je l'utilise moi même dans cette configuration mais avec un nombre de versions anciennes raisonnables : entre 10 et 15 par host (une douzaine de hosts).

        J'utilise BackupPC 4 en production depuis 2 ans, bien qu'il s'agisse d'une version alpha dont le développement semble s'être arrêté… Malheureusement.

  • # Ton NAS a un problème

    Posté par  . Évalué à 1.

    J’ai donc essayé rsync […] Après 1,5 an […] le backup n’est… pas fini

    Terminé il y a 3 semaines :
    rsync entre 2 NAS situés sur des sites différents (liaisons ADSL).
    Un NAS contenait 5 To de données répartis sur 200000 fichiers (ou 300000 je ne sais plus).
    L'autre NAS était vide.
    --> ça a pris 1,5 mois (il y a eu une coupure)
    --> la synchronisation actuelle dure 1h30 lorsqu'il n'y a presque aucun fichier modifié
    Pourtant ce sont de pauvres QNAP foireux à mort.

    Donc tu as un soucis avec ton NAS.

    Avis perso : les NAS sont TOUJOURS une mauvaise idée lorsqu'on s'y connaît un minimum (ce qui est ton cas). Ça coûte plus cher qu'un PC de récupération, et on ne peut pas l'utiliser tranquillement à coup de apt-get ou équivalent, ni recompiler rsync pour utiliser une version de développement afin de répondre à un besoin précis, ni installer ceci-cela sans faire des recherches interminables.
    Un bon NAS c'est juste un PC ou machine équivalente, avec 2 ou 4 disques. Si tu ne veux pas te palucher la configuration à la main, il y a des distributions toutes faites (de mémoire FreeNAS mais je ne sais pas si ça existe encore).

    • [^] # Re: Ton NAS a un problème

      Posté par  . Évalué à 8.

      Tu as oublié un truc. La structure en hard-link. C'est le point bloquant dans beaucoup de cas pour les systèmes qui les utilisent intensivement. Tu ne semble pas être dans le même cas, et utiliser ta propre expérience dans un cas non similaire ne peut se généraliser au problème de l'auteur. D'autant plus que le problème provient de justement ce qui diffère entre lui et toi, le nombre de hard-links.

    • [^] # Re: Ton NAS a un problème

      Posté par  . Évalué à 3.

      Ton test n'est peut-être pas équivalent s'il n'y a pas dans le NAS d'origine des millions de hardlinks. Parce qu'évidemment, c'est ça le fond du problème dans mon cas (c'est pour ça que j'insiste dessus dans l'intro et la conclusion).

      Mais il n'est pas impossible que mon NAS ait un problème : raison de plus pour en sauvegarder le contenu :-)

      Je trouve que les NAS ne sont pas une si mauvaise solution. Leur fermeture peut être pénible, mais on s'arrange (du côté QNAP on peut quand même y faire tourner plein de choses, et du côté de Synology, un chroot Debian assouplit énormément la situation !). Par contre, le matériel est de (très) bonne qualité et surtout, ça m'évite de passer beaucoup de temps dans des trucs dans lesquels je ne veux pas perdre de temps (c'est à dire la plupart des trucs en fait :-)). Avant de les avoir j'ai eu des PC divers et variés pour faire (ça allait de PC de récup à PC spécialement montés pour l'occasion), et je n'ai eu que des merdes jusqu'à, justement, une énorme perte de données.

      • [^] # Re: Ton NAS a un problème

        Posté par  . Évalué à 1.

        Mon autre commentaire plus haut parle d'une sauvegarde qui contient plusieurs millions de liens durs (non précisé dans le post) sur une machine de puissance ridicule.
        Mais pas un NAS : c'est un « vrai » OS.

        • [^] # Re: Ton NAS a un problème

          Posté par  . Évalué à 3.

          Mon autre commentaire plus haut parle d'une sauvegarde qui contient plusieurs millions de liens durs (non précisé dans le post) sur une machine de puissance ridicule.

          Alors là tu m'épates ! Comment rsync a pu gérer la RAM ? Il y a combien de RAM sur les NAS ?

          L'option -H est connue pour avaler goulument la RAM et tuer les perfs de rsync…
          (dans mon cas personnel on est monté à plus de 20Go de RAM, swappée bien sûr, sur du rsync natif : chroot Debain et non celui du NAS. Idem sur le rsync du QNAP et sur celui du Synology).

          • [^] # Re: Ton NAS a un problème

            Posté par  . Évalué à -2.

            Je ne sais pas répondre à ta question car je n'ai jamais vu rsync prendre 20 Go de mémoire. Ni même 5 Go.
            Je doute que rsync prenne plus de mémoire que la taille du fichier qu'il est en train de traiter, mais même en synchronisant des disques virtuels de quelques centaines de Go je n'ai jamais eu quoi que ce soit de notable.

            • [^] # Re: Ton NAS a un problème

              Posté par  . Évalué à 4. Dernière modification le 26 juillet 2016 à 22:22.

              Le problème est que rsync doit garder un mapping en mémoire des fichiers vers leur numéro d'inode original afin de pouvoir détecter les hard-link. Du coup, oui ça peut prendre beaucoup de mémoire, proportionnellement au nombre de fichiers et hard-links. L'avais-tu bien lancé avec -H ?

              • [^] # Re: Ton NAS a un problème

                Posté par  . Évalué à 1.

                L'avais-tu bien lancé avec -H ?

                Effectivement non, puisque ça n'a (généralement) pas d'intérêt.
                Par contre pour le problème de l'OP c'est nécessaire s'il tient à utiliser rsync.

                Dans ce cas j'aurais plutôt fait un « tar | lzop | ssh 'lzop' ». Ou sans lzop si les machines sont sur le même réseau local.

        • [^] # Re: Ton NAS a un problème

          Posté par  . Évalué à 3.

          Juste pour donner une idée des ordre de grandeurs en causes. Sur un serveur de sauvegarde (BackupPC, un petit, j'en ai un plus gros, mais faire des stats dessus pendrait trop de temps), qui fonctionne depuis une demi année (ce qui limite le nombre de hard-link), pour seulement 324 GiB, j'ai 4 millions d'inodes, et 56 millions de links (pour rappel, un fichier normal, c'est un inode + un link vers l'inode). C'est seulement sur 6 mois avec 324 GiB.

          Dans le cas de l'auteur, avec un truc qui tourne depuis 6 ans, et 2TiB de données, en gardant une granularité quotidienne (ce que je ne fais pas), si j'extrapole avec mon nombre de sauvegarde conservées et en considérant que le nombre de links par inode est une proportionnel au nombre de sauvegarde conservés, et que le considère que le nombre d'inodes est proportionnel au volume de données, cela donne 23 millions d'inodes et 27 milliards (oui 109) de links. Alors je ne connais pas exactement les chiffres de l'auteur du journal, mais on est loin de tes 2·105 à 3·105 inodes, et quelques millions de links.

          C'est justement stockage de cette équivalence entre links et inodes au fur et à mesure de la rencontre des links qui est problèmatique.

          Je me demande si par ailleurs, il n'y aurait pas moyen de développer un outil spécifique qui stockerai ces infos dans un stockage key/value adaptés aux très gros volume de données (dans le genre de LMDB).

    • [^] # Re: Ton NAS a un problème

      Posté par  . Évalué à 2.

      correction : liaisons SDSL, et non ADSL. Le site « sortant » a environ 20 Mb/s de débit montant.

  • # obnam : mon expérience

    Posté par  . Évalué à 4.

    J'utilisais BackupPC pour sauvegarder tout mon système, serveur et ordinateur personnel sur un même dépôt. Ça marchait très bien, mais j'ai eu le même problème que toi. La copie du dépôt de sauvegarde (sur un disque que je garde tout le temps avec moi) prend réellement 3 jours pour une faible quantité de données. J'utilisais rsync pour synchroniser la copie du dépôt, mais le problème est connu : les hardlinks.

    J'ai cherché d'autres solutions, aucune n'est parfaite et je suis resté sur obnam. Ça fait de la déduplication par bloc, et c'est donc stocké sur forme de chunk. La synchronisation de la copie du dépôt prend moins de 20 minutes avec rsync. C'est génial. Mes sauvegardes incrémentales (c'est le seul mode dans obnam) sont aussi plus rapides, puisque je fais une sauvegarde intégrale du système en 20 minutes :

    Backed up 1667 files (of 327296 found), containing 6.0 GiB.
Uploaded 369.0 MiB file data in 17m54s at 352.3 KiB/s average speed.
Total download amount 229.0 MiB.
Total upload amount 413.0 MiB. Overhead was 273.0 MiB (66.1 %).

    C'est un Atom D2550 qui sauvegarde sur un disque USB 2.0. La source est un disque interne 2"5. Rien de rapide, et pourtant, c'est suffisant.
    Avec obnam, la première sauvegarde sera longue, mais y a pas de magie.

    Par contre, j'ai eu des corruptions. Oui, c'est un gros défaut. Et non, je ne sais pas dire à quelle fréquence. Mais en général, la corruption n'arrive que sur un chunk, donc c'est limité…

  • # option backup de rsync

    Posté par  . Évalué à 7.

    Bonjour, pour info j'ai 6 ans de backup jour le jour, sans hardlink mais avec l'option backup de rsync.
    Plus d'info ici : http://linuxfocus.org/Francais/March2004/article326.shtml

    j'ai le dernier backup en sauvegarde complète, et chaque jour un répertoire avec uniquement ce qui a changé/effacé.
    C'est hyper pratique pour restaurer un crash complet et hyper rapide.
    La recherche d'un ancien ficher est laissé a l'utilisateur qui a accès a chaque répertoire d'archive en lecture seule et trié par date…

    pour externaliser un simple cp, ou rsync et c'est bon..

  • # Hardlinks

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

    Je pense comprendre l'intérêt des hardlinks (ne pas avoir plusieurs fois les mêmes données, j'imagine), mais je trouve ça particulièrement dangereux pour de la sauvegarde/archivage/redondance.
    En effet, si je modifie une seule sauvegarde (avec un simple >> , par exemple), toutes les copies précédentes sont également corrompues.
    Personnellement, quitte à garder tout l'historique, j'aurais pris du Subversion ou du Git. Au moins, pas de problème de hardlinks, avec tout l'historique et aucun problème de duplication (ou au moins pas plus qu'avec les hardlinks).

    • [^] # Re: Hardlinks

      Posté par  . Évalué à 2.

      Je pense comprendre l'intérêt des hardlinks (ne pas avoir plusieurs fois les mêmes données, j'imagine), mais je trouve ça particulièrement dangereux pour de la sauvegarde/archivage/redondance.
      En effet, si je modifie une seule sauvegarde (avec un simple >> , par exemple), toutes les copies précédentes sont également corrompues.

      – Tu évites ce genre de conneries sur le serveur de sauvegardes (typiquement, tu ne fais quasiment rien dessus à part le maintenir à jour et le cas échéant récupérer des fichiers) ; parce que si tu bouines des trucs sur le serveur de sauvegardes, tu peux endommager les sauvegardes, même sans lien hard (si tu utilises une autre méthode pour éviter de stocker les fichiers en double, et que tu en endommage un, tu n’es pas plus avancé…).
      – Si tu exportes les sauvegardes en NFS ou autre, c’est en lecture seule.

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Avancée...

    Posté par  . Évalué à 2.

    Une petite mise à jour…

    À la suite de vos nombreuses recommandations (merci !), j’ai décidé de tester deux cas :

    1. re-tester cp -a suivi d’un rsync pour valider la copier
    2. essayer avec un find -mtime xxx de récolter les dernières mises à jour et faire un rsync avec

    Pour l’instant, j’en suis au 1. et les résultats sont excellents !

    J’ai testé le cp -a sur le même échantillon que le test de BUP présenté dans le journal (~20 % des octets et des hardlinks) et le cp n’a pris que 4 h le rsync de validation quelques heures aussi.

    Je vais donc tester sur une plus grosse partie du backup (60 % des données et des hardlinks).

    Merci à gUI pour cette piste que j’avais écartée jadis je ne sais plus pourquoi, mais qui semble très prometteuse.

    • [^] # Re: Avancée...

      Posté par  . Évalué à 3.

      Par curiosité, combien as-tu d'inodes sur ton NAS ?

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

      • [^] # Re: Avancée...

        Posté par  . Évalué à 1.

        le comptage est commencé… je te tiens au courant…

        • [^] # Re: Avancée...

          Posté par  (Mastodon) . Évalué à 3. Dernière modification le 27 juillet 2016 à 12:10.

          Ne me dis pas que tu les comptes avec find alors que df -i peut te donner cette info immédiatement…

          • [^] # Re: Avancée...

            Posté par  . Évalué à 2.

            Alors donc je te le dis pas… :-)

            Et je donne le résultat (plus rapide que prévu :-)):

            Inodes   IUsed   IFree IUse%
365993984 44973429 321020555   13%

            • [^] # Re: Avancée...

              Posté par  . Évalué à 3.

              merci :)

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

              • [^] # Re: Avancée...

                Posté par  . Évalué à 1.

                NB: Les hardlinks n'utilisent pas d'inodes supplémentaires…

  • # Pourquoi pas deux backups plutôt qu'un backup de backup ?

    Posté par  . Évalué à 1. Dernière modification le 27 juillet 2016 à 11:17.

    Plutôt que de tenter de backuper un backup avec des milliards de hard links (ce qui semble poser problème), ne serait-il pas préférable d'avoir deux backups en parallèle ? Si on en perd un on a toujours l'autre et plus de problème avec les hard links.

    PS. Je suis conscient que ça ne résout pas le problème de l'auteur du post qui a déjà son unique backup…

    • [^] # Re: Pourquoi pas deux backups plutôt qu'un backup de backup ?

      Posté par  . Évalué à 1.

      Oui, c'est une bonne idée (qui a d'ailleurs déjà été proposée dans un autre commentaire). On pet même imaginer un système de vérification entre les deux supports de la sauvegarde.

    • [^] # Re: Pourquoi pas deux backups plutôt qu'un backup de backup ?

      Posté par  . Évalué à 1.

      Je me demande si https://syncthing.net/ ne résoudrait pas le problème.
      Attention, c'est en retard d'une version -et incompatible- sur synology en ce moment. Mais à jour sur OpenMediaVault -basé sur wheezy- et Debian.

      • [^] # Re: Pourquoi pas deux backups plutôt qu'un backup de backup ?

        Posté par  . Évalué à 3.

        Il reproduit aussi les suppressions… En cas de crash ça va, en cas de suppression des données pour une autre raison (mauvaise manip', attaque,…) t'es mort…

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

        • [^] # Re: Pourquoi pas deux backups plutôt qu'un backup de backup ?

          Posté par  . Évalué à 1.

          Tu peux le paramétrer afin qu'il garde les fichiers supprimés (actif par défaut il me semble).

          Et là d'ailleurs ça te permet de faire ton backup vers X serveurs simultanément sachant que le fonctionnement est en p2p donc un serveur de backup pourra envoyer lui même les fichiers déjà reçus vers un autre serveur de backup afin de décharger le serveur principal ;)

  • # dd des familles

    Posté par  . Évalué à 1.

    Juste une solution à deux francs : si ton NAS a un port USB, pourrais tu y brancher un disque dur avec une partition de même taille et juste utiliser la commande "dd" pour copier à l'identique dessus ?
    Après tu débranche le disque.
    Tu répète l'opération tous les 2 mois par exemple.

    Je sais que les trucs manuels c'est pas ce qu'on cherche souvent pour les sauvegardes, mais ça te permettrais peut être de dormir tranquille, au moins le temps de trouver une autre solution :-)

    • [^] # Re: dd des familles

      Posté par  . Évalué à 6.

      Tu peux aussi le faire sans USB (dd et nc c'est vraiment puissant) :

      • sur le NAS qui reçoit les données :
      nc -lp 8888 > backup-$(date +%F).data.gz
      • sur le NAS qui envoie les données :
      dd if=/dev/sda | gz | nc 192.168.1.12 8888

      C'est assez pratique. Pour la pertinence de gzipé ou non les données, je laisse les spécialistes en parler (je l'ai mis juste pour montrer que c'est possible).

      Évidement si tu veux traverser internet et utiliser une connexion sécuriser, tu peux utiliser ssh. En faisant sur le NAS qui envoie les données :

      ssh -L 4444:localhost:8888 user@exemple.org
dd if=/dev/sda | gz | nc localhost 8888

      Évidement il faut alors lancer netcat ainsi (histoire de ne pas exposer ton serveur de backup aux 4 vents) :

      nc -lp 8888 -s 127.0.0.1 > backup-$(date +%F).data.gz

      Coté serveur, là je l'envoie dans un fichier mais on peut très bien envoyer le tout directement dans une partition :

      nc -lp 8888 | gunzi | dd of=/dev/sda

      Je montre netcat parce que c'est celui que je connais, je ne doute pas que socat fait très bien le boulot. Par contre il vaut mieux éviter ddrescue qui n'effectue pas une lecture linéaire.

      L'avantage de tout ça c'est que tu peux le mettre dans une crontab.

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

      • [^] # Re: dd des familles

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

        C'est assez pratique. Pour la pertinence de gzipé ou non les données, je laisse les spécialistes en parler (je l'ai mis juste pour montrer que c'est possible).

        Je veux juste compléter ton excellent commentaire en faisant cette petite comparaison:

        • Si on ne compresse pas les données, cela prend beaucoup plus de place mais on peut faire plus de choses, par exemple utiliser l'image du disque à travers un device approprié – autrement dit on peut lire la sauvegarde sans la restaurer avant.

        • Si on compresse les données avec gzip on sauve de la place (sur le réseau et sur la machine) en échange de temps de calcul, et on ne peut en principe plus accéder directement à la sauvegarde.

        • Si on compresse les données avec xzip on sauve beaucoup de place en échange de beaucoup de temps de calcul et on ne peut pas non plus accéder directement à la sauvegarde.

        C'est probablement une assez mauvaise idée d'utiliser xzip sur le NAS à cause de la puissance de calcul nécessaire, mais si la sauvegarde arrive sur une machine plus costaude et que le réseau reliant les machine a un bon début, tu peux aussi déplacer la compression sur la machine destination et considérer xzip dans tes options.

        Pour info, xzip peut compresser 700 Go de logs en 30 Mo – il s'agit évidemment de données ultra redondantes – un ratio que gzip n'atteint ni en rêve ni ailleurs. En revanche gzip est beaucoup plus rapide et moins gourmand en ressources.

      • [^] # Re: dd des familles

        Posté par  . Évalué à 10.

        Évidement si tu veux traverser internet et utiliser une connexion sécuriser, tu peux utiliser ssh. En faisant sur le NAS qui envoie les données :

        ssh -L 4444:localhost:8888 user@exemple.org
dd if=/dev/sda | gz | nc localhost 8888

        Évidement il faut alors lancer netcat ainsi (histoire de ne pas exposer ton serveur de backup aux 4 vents) :

        nc -lp 8888 -s 127.0.0.1 > backup-$(date +%F).data.gz

        Mais What? Lancer un ssh pour assurer un tunnel tcp, et après aller sur la machine distance pour mettre quelqu'un au bout du tunnel tcp… C'est lourd. Pourquoi ne juste pas utiliser ceci qui suit ?

        dd if=/dev/sda | gzip | ssh user@example.org "cat > backup-$(date +%F).data.gz"

        • [^] # Re: dd des familles

          Posté par  . Évalué à 4.

          Ok je ne connaissais pas, je ne sais si la différence est sensible. Je voulais surtout montrer qu'il fallait une sécurité.

          En terme de performance ajuster les tampons de dd est assez important des tests que j'avais fais.

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

        • [^] # Re: dd des familles

          Posté par  . Évalué à 3.

          C'est lourd.

          Je suis pris d'un doute…

          Coté serveur tu passe à un ssh qui déchiffre, puis puis envoie les données décapsulées de la trame tcp sur un pipe pour que cat l'écrive dans un fichier et avant c'était ssh déchiffre et envoie tel quel sur un autre port où netcat décapsule les trame et les écris sur disque. Le coût du tunnel tcp est vraiment très faible pour ce que j'ai pu essayer. Je n'ai pas réussi à en mesurer l'impact pour moi s'il y en a un il n'est pas mesurable. Du coup j'aurais une préférence pour l'utilisation de netcat car :

          • elle réparti le travail entre ssh et celui qui écris (on parle de presque rien, mais comme tu considère « lourd » ce genre de presque rien…), c'est important de répartir la charge de travaille entre les étages de ton pipeline parce que le débit de celui-ci dépend (entre autre) de l'étage le plus lent
          • en cas de disque particulièrement lent le pipe est un buffer de 4kio alors que la socket tcp a des buffers bien plus larges
          • je peux faire des envoies multiple dans divers sens avec des tunnels tcp
          • je peux utiliser la même connexion ssh facilement (sans avoir besoin de faire du multiplexage ssh) pour faire autre chose ou surveiller que les copies se passent bien

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

Suivre le flux des commentaires

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