• # cette solution est un ptar (mouillé)

    Posté par  . Évalué à 10 (+10/-1).

    ---->[]

  • # Super

    Posté par  . Évalué à 4 (+2/-0).

    C'est une super initiative, c'est vrai que ça manque. Je connais Zed! qui fait ça, mais c'est propriétaire.

    • [^] # Re: Super

      Posté par  (site web personnel) . Évalué à 10 (+11/-0).

      Hello, auteur de ptar ici.

      Je ne connaissais pas Zed, je vais regarder ca pour voir s’il y a un écart a combler en terme de fonctionnalités, mais je pense qu’on est déjà pas mal pratique :-)

      Notre code est publie sous license ISC histoire de garantir que le format reste ouvert, je vais publier dans quelques jours une documentation du format pour permettre a quiconque d’écrire sa propre implementation.

      Merci pour le partage et le commentaire :-)

      • [^] # Re: Super

        Posté par  . Évalué à 5 (+3/-0).

        Ca me fait aussi penser à zpaq :
        https://mattmahoney.net/dc/zpaq.html

        • [^] # Re: Super

          Posté par  (site web personnel) . Évalué à 3 (+2/-0).

          Oui il y a quelques similitudes mais dans notre approche le format est verrouillé une fois crée, il n'y a plus d'append possible, l'archive est considérée comme "altérée" et corrompue en cas de modifications.

          Pour produire un comportement à la zpaq, en ajout de donnée, il faut prendre en entrée un autre .ptar + le contenu à ajouter pour générer une nouvelle archive:

          $ plakar ptar -o nouveau.ptar -k ancien.ptar /chemin/vers/les/donnees/a/ajouter

        • [^] # Re: Super

          Posté par  . Évalué à 4 (+2/-0).

          Ça ressemble pas mal à zpaq, mais si j'ai bonne mémoire, zpaq est leeeent. Et ptar n'est pas incrémental, c'est plutôt une fonctionnalité de son point de vue.

      • [^] # Re: Super

        Posté par  . Évalué à 6 (+4/-0).

        L'ensemble ressemble aussi beaucoup à Restic et Kopia non ?

        • [^] # Re: Super

          Posté par  . Évalué à 4 (+2/-0).

          plakar est un gestionnaire de sauvegardes, donc oui, il « ressemble » à restic / kopia / borg parce qu'il fait de la déduplication, compression, chiffrement.

          Par contre ptar est une fonctionnalité à part entière, qui est pour l'instant liée à plakar, mais qui pourrait avoir vocation à avoir son écosystème d'outils séparément.

          • [^] # Re: Super

            Posté par  (site web personnel) . Évalué à 4 (+3/-0).

            Hier, j'ai commencé à écrire kapsule un outil spécifique à .ptar, j'espère avoir quelque chose de publiable dans les dix jours :-p

            • [^] # Re: Super

              Posté par  . Évalué à 3 (+1/-0).

              Je note : 10 jours. Tic-tac, tic-tac ;)

              Je précise : c'est une blague, ne pas oublier de prendre du temps pour soi, l'écriture d'un logiciel ne peut pas passer au dessus de sa santé, voilà voilà.

              Mais ça fait plaisir quand c'est bien fait et qu'il résout un problème.

              • [^] # Re: Super

                Posté par  (site web personnel) . Évalué à 5 (+4/-0).

                haha, crédible néanmoins:

                $ kapsule ls -f test.ptar           
2025-06-02T19:43:53Z   ed0f6603    3.1 MB        0s /private/etc

$ kapsule ls -f test.ptar ed:ssl
2025-02-04T16:57:51Z -rw-r--r--     root    wheel   334 kB cert.pem
2025-02-04T16:57:51Z drwxr-xr-x     root    wheel     64 B certs
2025-02-04T16:57:51Z -rw-r--r--     root    wheel    745 B openssl.cnf
2025-02-04T16:57:51Z -rw-r--r--     root    wheel   1.0 kB x509v3.cnf

                on a monté une boite et on bosse 100% sur plakar et liés, donc ça fait partie de notre taff de faire ce genre de choses en 10 jours :-p

            • [^] # Re: Super

              Posté par  . Évalué à 3 (+1/-0).

              https://www.plakar.io/posts/2025-07-07/kapsul-a-tool-to-create-and-manage-deduplicated-compressed-and-encrypted-ptar-vaults/

              Le 7 juillet, pas mal, ça fait 7 jours, bien joué :)

        • [^] # Re: Super

          Posté par  (site web personnel) . Évalué à 3 (+2/-0).

          Oui, les trois projets ont beaucoup de similitudes sur leur fonctionnement (repository de données, snapshot d'un delta avec un algo de CDC, …) mais des approches différentes pour résoudre le problème des sauvegardes et des philosophies différentes sur comment les utilisateurs voient les sauvegardes.

          Je peux répondre à toutes vos questions là dessus :-)

      • [^] # Re: Super

        Posté par  . Évalué à 4 (+3/-0).

        Suggestion de fritures:

        • utilisation de certificats x509 pour le chiffrement
        • prise en compte des token PKCS#11 pour le stockage du certificat
        • chiffrement multi-utilisateur, ie plusieurs certificats peuvent déchiffrer
        • recherche de certificats dans un annuaire LDAP
        • authentification Kerberos sur le LDAP

        Note : je n'ai pas lu la liste des fonctionnalités de ptar, mais je suis un utilisateurs de Zed. Les fonctionnalités ci-dessus existe dans Zed … sauf la dernière.

      • [^] # Re: Super

        Posté par  . Évalué à 4 (+2/-0).

        Point négatif, Zed est bien privateur : https://www.primx.eu/fr/encryption-software/zed/

        Par contre, ça peut intéresser des gens parce que :

        ZED! a obtenu les certifications :

        CERTIFICATION CRITÈRES COMMUNS AU NIVEAU EAL3+
        VISA DE SÉCURITÉ ANSSI ET QUALIFICATION NIVEAU STANDARD
        PROTECTION DES DONNEES MARQUEES DIFFUSION RESTREINTE UE
        PROTECTION DES DONNEES MARQUEES DIFFUSION RESTREINTE OTAN

        • [^] # Re: Super

          Posté par  (site web personnel) . Évalué à 4 (+3/-0).

          On ne visait pas ces certifications mais pourquoi pas

          • [^] # Re: Super

            Posté par  . Évalué à 4 (+2/-0).

            Quand c'est prêt, faire un financement participatif pour obtenir le visa de sécurité de l'ANSSI a du sens : format ouvert, code ouvert, audité et certifié, l'État a tout à y gagner :).

            Le truc pénible, c'est que la certification vaut pour une version spécifique, ce qui mène à avoir une ligne "LTS" qui ne bouge pas, et une version qui vit sa vie.

  • # Je trouve ce projet super intéressant !

    Posté par  . Évalué à 4 (+2/-0).

    Merci pour cette belle découverte et le travail derrière !

    Il m'arrive de batailler avec des archives sous format zip faute de mieux, même si je me dis à chaque fois que ça semble en effet être de la pré-histoire peu efficace et manquant de fonctionnalités.

    Quelle volumétrie peut-t-on adresser avec planka/ptar ?

    Comment se comporte le format .ptar à l'ajout de fichier ? Le fichier est massivement modifié ? (Je pense notamment à de la synchro via syncthing par exemple)

    Le nombre de snapshots est limité ou peut poser problème au delà d'un certain usage ?

    Comment le projet plakar se positionne par rapport à borgbackup ou https://dvc.org/ par exemple ? (le format .ptar semble à première vue un gros avantage à mes yeux pour le partage/transfert et peut-être plus "léger" qu'avoir toute une arborescence à synchroniser)

    Le format .ptar a pour objectif de remplacer le format "repo" ?

    Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables …) (oui, oui, 3-2-1-0)

    J'aime beaucoup l'ui intégrée également ! (ce que borg ne propose pas de mémoire)

    • [^] # Re: Je trouve ce projet super intéressant !

      Posté par  (site web personnel) . Évalué à 4 (+3/-0).

      Merci pour cette belle découverte et le travail derrière !

      merci <3

      Quelle volumétrie peut-t-on adresser avec planka/ptar ?

      En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)

      En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..

      Comment se comporte le format .ptar à l'ajout de fichier ? Le fichier est massivement modifié ? (Je pense notamment à de la synchro via syncthing par exemple)

      Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.

      Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.

      Le nombre de snapshots est limité ou peut poser problème au delà d'un certain usage ?

      Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.

      Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.

      Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.

      Comment le projet plakar se positionne par rapport à borgbackup ou https://dvc.org/ par exemple ? (le format .ptar semble à première vue un gros avantage à mes yeux pour le partage/transfert et peut-être plus "léger" qu'avoir toute une arborescence à synchroniser)

      Pas certain de comprendre la question du positionnement, désolé.

      Le format .ptar a pour objectif de remplacer le format "repo" ?

      Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)

      Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables …) (oui, oui, 3-2-1-0)

      Long débat, on n'est pas encore convaincu de l'utilité:

      Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif… si l'on considère qu'un second dépôt offre une correction totale.

      On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.

      J'aime beaucoup l'ui intégrée également ! (ce que borg ne propose pas de mémoire)

      Merci <3

      • [^] # Re: Je trouve ce projet super intéressant !

        Posté par  . Évalué à 2 (+0/-0).

        il faut que quelqu'un teste :-)

        Comme disait le chanteur, je n'ai qu'une seule vie.

        il n'y théoriquement rien qui permet de monter beaucoup plus haut..

        J'imagine que c'est « il n'y a […] rien qui permet de ne pas monter beaucoup plus haut » ?

        Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables …) (oui, oui, 3-2-1-0)

        Long débat, on n'est pas encore convaincu de l'utilité:

        Je pense qu'il vaut mieux laisser ça à un conteneur supplémentaire dont c'est vraiment le boulot : https://en.wikipedia.org/wiki/Parchive

Envoyer un commentaire

Suivre le flux des commentaires

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