{"id":35003,"date":"2019-10-31T22:01:46","date_gmt":"2019-10-31T19:01:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup\/"},"modified":"2019-10-31T22:01:46","modified_gmt":"2019-10-31T19:01:46","slug":"rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Sauvegarde, partie 4 : Aper\u00e7u et test de zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sauvegarde,<\/p>\n

<\/p>\n

Cet article examinera les outils logiciels de sauvegarde qui, en fragmentant le flux de donn\u00e9es en composants distincts (chunks), forment un r\u00e9f\u00e9rentiel.<\/p>\n

<\/p>\n

Les composants du r\u00e9f\u00e9rentiel peuvent \u00e9galement \u00eatre compress\u00e9s et chiffr\u00e9s, et surtout, lors des processus de sauvegarde r\u00e9p\u00e9t\u00e9s, \u00eatre r\u00e9utilis\u00e9s.<\/p>\n

<\/p>\n

Une sauvegarde dans un tel r\u00e9f\u00e9rentiel est une cha\u00eene nomm\u00e9e de composants li\u00e9s entre eux, par exemple, sur la base de diff\u00e9rentes fonctions de hachage.<\/p>\n

<\/p>\n

Il existe plusieurs solutions similaires, je vais m'arr\u00eater sur 3 : zbackup, borgbackup et restic.<\/p>\n

<\/a><\/noindex><\/p>\n

R\u00e9sultats attendus<\/h3>\n

<\/p>\n

\u00c9tant donn\u00e9 que tous les candidats n\u00e9cessitent d'une mani\u00e8re ou d'une autre la cr\u00e9ation d'un r\u00e9f\u00e9rentiel, l'un des facteurs les plus importants sera l'\u00e9valuation de la taille du r\u00e9f\u00e9rentiel. Dans l'id\u00e9al, sa taille ne devrait pas d\u00e9passer 13 Go selon la m\u00e9thode adopt\u00e9e, voire moins, \u00e0 condition d'une bonne optimisation.<\/p>\n

<\/p>\n

Il est \u00e9galement fortement souhaitable de pouvoir cr\u00e9er des sauvegardes de fichiers directement, sans utiliser d'archiveurs comme tar, ainsi que de travailler avec ssh\/sftp sans outils suppl\u00e9mentaires comme rsync et sshfs.<\/p>\n

<\/p>\n

Comportement lors de la cr\u00e9ation de sauvegardes :<\/strong><\/p>\n

<\/p>\n

    \n
  1. La taille du r\u00e9f\u00e9rentiel sera \u00e9gale \u00e0 la taille des modifications, ou inf\u00e9rieure.<\/li>\n
  2. On s'attend \u00e0 une grande charge sur le processeur lors de l'utilisation de la compression et\/ou du chiffrement, ainsi qu'\u00e0 une charge assez importante sur le r\u00e9seau et le sous-syst\u00e8me de stockage, si le processus d'archivage et\/ou de chiffrement fonctionne sur le serveur de stockage des sauvegardes.<\/li>\n
  3. Si le r\u00e9f\u00e9rentiel est endommag\u00e9, il peut y avoir une erreur diff\u00e9r\u00e9e tant lors de la cr\u00e9ation de nouvelles sauvegardes que lors de la tentative de restauration. Il est n\u00e9cessaire de planifier des mesures suppl\u00e9mentaires pour garantir l'int\u00e9grit\u00e9 du r\u00e9f\u00e9rentiel ou d'utiliser des outils int\u00e9gr\u00e9s pour v\u00e9rifier son int\u00e9grit\u00e9.<\/li>\n<\/ol>\n

    <\/p>\n

    La r\u00e9f\u00e9rence est le travail avec tar, comme cela a \u00e9t\u00e9 montr\u00e9 dans l'un des pr\u00e9c\u00e9dents articles.<\/p>\n

    <\/p>\n

    Test du zbackup<\/h3>\n

    <\/p>\n

    Le m\u00e9canisme g\u00e9n\u00e9ral de fonctionnement de zbackup est que le programme trouve dans le flux de donn\u00e9es fourni en entr\u00e9e des zones contenant des donn\u00e9es identiques, puis les compresse, les chiffre \u00e9ventuellement, en conservant chaque zone uniquement une fois.<\/p>\n

    <\/p>\n

    Pour la d\u00e9duplication, une fonction de hachage circulaire 64 bits avec une fen\u00eatre glissante est utilis\u00e9e pour la v\u00e9rification byte \u00e0 byte en correspondance avec des blocs de donn\u00e9es d\u00e9j\u00e0 existants (similaire \u00e0 ce qui est r\u00e9alis\u00e9 dans rsync).<\/p>\n

    <\/p>\n

    Pour la compression, llzma et lzo sont utilis\u00e9s en mode multithread, et pour le chiffrement, l'aes. Dans les derni\u00e8res versions, il est possible de supprimer \u00e0 l'avenir les anciennes donn\u00e9es du d\u00e9p\u00f4t.
    \nLe programme est \u00e9crit en C++ avec un minimum de d\u00e9pendances. L\u2019auteur semble s'\u00eatre inspir\u00e9 du unix-way, car le programme accepte les donn\u00e9es sur stdin lors de la cr\u00e9ation de sauvegardes, produisant un flux de donn\u00e9es similaire sur stdout lors de la restauration. Ainsi, zbackup peut \u00eatre utilis\u00e9 comme un tr\u00e8s bon \u00ab brique \u00bb pour cr\u00e9er ses propres solutions de sauvegarde. Par exemple, pour l\u2019auteur de l\u2019article, ce programme est le principal outil de sauvegarde pour les machines domestiques depuis environ 2014.<\/p>\n

    <\/p>\n

    Un tar standard sera utilis\u00e9 comme flux de donn\u00e9es, sauf indication contraire.<\/p>\n

    \nVoyons quels seront les r\u00e9sultats :<\/b><\/p>\n

    Le test a \u00e9t\u00e9 effectu\u00e9 dans 2 variantes :<\/p>\n

    <\/p>\n

      \n
    1. un d\u00e9p\u00f4t est cr\u00e9\u00e9 et zbackup est lanc\u00e9 sur le serveur avec les donn\u00e9es d'origine, puis le contenu du d\u00e9p\u00f4t est transf\u00e9r\u00e9 sur le serveur de stockage des sauvegardes.<\/li>\n
    2. un d\u00e9p\u00f4t est cr\u00e9\u00e9 sur le serveur de stockage des sauvegardes, zbackup est lanc\u00e9 via ssh sur le serveur de stockage des sauvegardes, et les donn\u00e9es lui sont transmises via un pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Les r\u00e9sultats de la premi\u00e8re variante \u00e9taient les suivants : 43m11s \u2014 avec un d\u00e9p\u00f4t non chiffr\u00e9 et le compresseur lzma, 19m13s \u2014 en rempla\u00e7ant le compresseur par lzo.<\/p>\n

      <\/p>\n

      La charge sur le serveur avec les donn\u00e9es d'origine \u00e9tait la suivante (exemple avec lzma, avec lzo c'\u00e9tait \u00e0 peu pr\u00e8s la m\u00eame image, mais la part de rsync \u00e9tait d'environ le quart du temps) :<\/p>\n

      <\/p>\n

      \"Sauvegarde,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Il est clair qu'un tel processus de sauvegarde n'est appropri\u00e9 que pour des changements relativement rares et petits. Il est \u00e9galement fortement recommand\u00e9 de limiter le travail de zbackup \u00e0 1 thread, sinon la charge processeur sera tr\u00e8s \u00e9lev\u00e9e, car le programme peut efficacement fonctionner en plusieurs threads. La charge sur le disque \u00e9tait faible, ce qui, dans l'ensemble, sera imperceptible avec un syst\u00e8me de disque moderne bas\u00e9 sur ssd. Il est \u00e9galement clair que le processus de synchronisation des donn\u00e9es du d\u00e9p\u00f4t sur un serveur distant est comparable en vitesse \u00e0 un rsync normal et est limit\u00e9 par les performances du syst\u00e8me de disque du serveur de stockage des sauvegardes. Un inconv\u00e9nient de cette approche est le stockage d'un d\u00e9p\u00f4t local et, par cons\u00e9quent, la duplication des donn\u00e9es.<\/p>\n

      <\/p>\n

      Le deuxi\u00e8me sc\u00e9nario, qui consiste \u00e0 lancer zbackup directement sur le serveur de stockage des sauvegardes, est plus int\u00e9ressant et applicable en pratique.<\/p>\n

      <\/p>\n

      Pour commencer, nous allons tester le fonctionnement sans utiliser le chiffrement avec le compresseur lzma :<\/p>\n

      <\/p>\n

      \"Sauvegarde,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Temps d'ex\u00e9cution de chaque lancement de test :<\/p>\n

      <\/p>\n

      Lancement 1
      \nLancement 2
      \nLancement 3<\/p>\n

      39m45s
      \n40m20s
      \n40m3s<\/p>\n

      7m36s
      \n8m3s
      \n7m48s<\/p>\n

      15m35s
      \n15m48s
      \n15m38s<\/p>\n

      <\/p>\n

      Lorsque l'on active le chiffrement avec aes, les r\u00e9sultats sont assez similaires :<\/p>\n

      <\/p>\n

      \"Sauvegarde,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Temps d'ex\u00e9cution sur les m\u00eames donn\u00e9es, avec chiffrement :<\/p>\n

      <\/p>\n

      Lancement 1
      \nLancement 2
      \nLancement 3<\/p>\n

      43m40s
      \n44m12s
      \n44m3s<\/p>\n

      8m3s
      \n8m15s
      \n8m12s<\/p>\n

      15m0s
      \n15m40s
      \n15m25s<\/p>\n

      <\/p>\n

      Si le chiffrement est combin\u00e9 avec la compression lzo, les r\u00e9sultats sont les suivants :<\/p>\n

      <\/p>\n

      \"Sauvegarde,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Temps d'ex\u00e9cution :<\/p>\n

      <\/p>\n

      Lancement 1
      \nLancement 2
      \nLancement 3<\/p>\n

      18m2s
      \n18m15s
      \n18m12s<\/p>\n

      5m13s
      \n5m24s
      \n5m20s<\/p>\n

      8m48s
      \n9m3s
      \n8m51s<\/p>\n

      <\/p>\n

      La taille du d\u00e9p\u00f4t r\u00e9sultant \u00e9tait relativement constante et s'\u00e9levait \u00e0 13 Go. Cela signifie que la d\u00e9duplication fonctionne correctement. De plus, l'application de lzma sur des donn\u00e9es d\u00e9j\u00e0 compress\u00e9es a un effet significatif, et le temps de traitement total de zbackup se rapproche fortement de duplicity\/duplicati, bien qu'il soit encore \u00e0 la tra\u00eene par rapport \u00e0 ceux bas\u00e9s sur librsync de 2 \u00e0 5 fois.<\/p>\n

      <\/p>\n

      Les avantages sont \u00e9vidents \u2014 \u00e9conomies d'espace disque sur le serveur de stockage des sauvegardes. En ce qui concerne les outils de v\u00e9rification du d\u00e9p\u00f4t, ils ne sont pas pr\u00e9vus par l'auteur de zbackup, il est recommand\u00e9 d'utiliser un ensemble de disques tol\u00e9rant aux pannes ou un fournisseur de services cloud.<\/p>\n

      <\/p>\n

      Dans l'ensemble, une impression plut\u00f4t bonne, malgr\u00e9 le fait que le projet est stagnant depuis environ 3 ans (la derni\u00e8re demande de fonctionnalit\u00e9 date d'une ann\u00e9e, mais sans r\u00e9ponse).<\/p>\n

      <\/p>\n

      Test de borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup est un fork de attic, un autre syst\u00e8me similaire \u00e0 zbackup. \u00c9crit en python, il a une liste de fonctionnalit\u00e9s similaire \u00e0 zbackup, mais est capable de :<\/p>\n

      <\/p>\n