{"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\/sv\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Backup, del 4: \u00d6versikt och test av zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

I denna artikel kommer programvaror f\u00f6r s\u00e4kerhetskopiering att behandlas, vilka genom att dela upp datastreamen i separata komponenter (chunks), formar ett repository.<\/p>\n

<\/p>\n

Repositorykomponenter kan dessutom komprimeras och krypteras, och viktigast av allt \u2013 vid upprepade s\u00e4kerhetskopieringsprocesser \u2013 \u00e5teranv\u00e4ndas.<\/p>\n

<\/p>\n

En s\u00e4kerhetskopia i ett s\u00e5dant repository \u00e4r en namngiven kedja av relaterade komponenter, till exempel baserat p\u00e5 olika hash-funktioner.<\/p>\n

<\/p>\n

Det finns flera liknande l\u00f6sningar, jag kommer att fokusera p\u00e5 3: zbackup, borgbackup och restic.<\/p>\n

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

F\u00f6rv\u00e4ntade resultat<\/h3>\n

<\/p>\n

Eftersom alla kandidater mer eller mindre kr\u00e4ver skapande av ett repository, kommer en av de viktigaste faktorerna att vara bed\u00f6mning av repositoryts storlek. I idealfallet b\u00f6r dess storlek inte \u00f6verstiga 13 GB enligt den vedertagna metoden, ja, eller till och med mindre \u2013 under f\u00f6ruts\u00e4ttning av god optimering.<\/p>\n

<\/p>\n

Det \u00e4r ocks\u00e5 starkt \u00f6nskv\u00e4rt att ha m\u00f6jlighet att skapa s\u00e4kerhetskopior av filer direkt, utan att anv\u00e4nda arkiveringsverktyg som tar, samt att arbeta med ssh\/sftp utan ytterligare verktyg som rsync och sshfs.<\/p>\n

<\/p>\n

Beteende vid skapande av s\u00e4kerhetskopior:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Repositoryts storlek kommer att motsvara storleken p\u00e5 f\u00f6r\u00e4ndringarna, eller vara mindre.<\/li>\n
  2. Stora processorbelastningar f\u00f6rv\u00e4ntas vid anv\u00e4ndning av komprimering och\/eller kryptering, och en ganska stor belastning p\u00e5 n\u00e4tverket och disksubsystemet kan ocks\u00e5 f\u00f6rekomma, om arkiverings- och\/eller krypteringsprocessen k\u00f6rs p\u00e5 backupservern.<\/li>\n
  3. Om repositoryt skadas \u2013 finns det risk f\u00f6r f\u00f6rdr\u00f6jd fel vid b\u00e5de skapande av nya s\u00e4kerhetskopior och vid f\u00f6rs\u00f6k till \u00e5terst\u00e4llning. Ytterligare \u00e5tg\u00e4rder f\u00f6r att s\u00e4kerst\u00e4lla repositoryts integritet b\u00f6r planeras eller s\u00e5 b\u00f6r inbyggda verktyg f\u00f6r att kontrollera dess integritet anv\u00e4ndas.<\/li>\n<\/ol>\n

    <\/p>\n

    Som referensv\u00e4rde antas arbete med tar, som visats i en av tidigare artiklar.<\/p>\n

    <\/p>\n

    Test av zbackup<\/h3>\n

    <\/p>\n

    Den allm\u00e4nna arbetsmekanismen f\u00f6r zbackup \u00e4r att programmet s\u00f6ker i datastreamen som matas in, efter omr\u00e5den som inneh\u00e5ller samma data, sedan komprimerar och krypterar det valfritt, och sparar varje omr\u00e5de endast en g\u00e5ng.<\/p>\n

    <\/p>\n

    F\u00f6r deduplicering anv\u00e4nds en 64-bitars ringhash-funktion med glidande f\u00f6nster f\u00f6r byte-f\u00f6r-byte-kontroll av \u00f6verensst\u00e4mmelse med redan existerande datablokker (liknande hur det implementeras i rsync).<\/p>\n

    <\/p>\n

    F\u00f6r komprimering anv\u00e4nds lzma och lzo i flertr\u00e5dad utf\u00f6rande, och f\u00f6r kryptering anv\u00e4nds aes. I de senaste versionerna finns m\u00f6jlighet att i framtiden ta bort gamla data fr\u00e5n lagringsf\u00f6rr\u00e5det.
    \nProgrammet \u00e4r skrivet i C++ med minimala beroenden. F\u00f6rfattaren tycks ha inspirerats av unix-way, s\u00e5 programmet tar emot data p\u00e5 stdin n\u00e4r det skapar s\u00e4kerhetskopior, och ger ut en liknande datastream p\u00e5 stdout vid \u00e5terst\u00e4llning. P\u00e5 s\u00e5 s\u00e4tt kan zbackup anv\u00e4ndas som en mycket bra \"kloss\" f\u00f6r att skriva egna s\u00e4kerhetskopieringsl\u00f6sningar. Till exempel har f\u00f6rfattaren av artikeln anv\u00e4nt detta program som sitt huvudsakliga verktyg f\u00f6r s\u00e4kerhetskopiering av hemmadatorer sedan 2014.<\/p>\n

    <\/p>\n

    Som datastream kommer vanlig tar att anv\u00e4ndas, om inget annat anges.<\/p>\n

    \nL\u00e5t oss se vilka resultat som kommer att bli:<\/b><\/p>\n

    Prestandatestet utf\u00f6rdes i 2 varianter:<\/p>\n

    <\/p>\n

      \n
    1. ett lagringsf\u00f6rr\u00e5d skapas och zbackup k\u00f6rs p\u00e5 servern med k\u00e4lldata, sedan \u00f6verf\u00f6rs inneh\u00e5llet i lagringsf\u00f6rr\u00e5det till servern f\u00f6r s\u00e4kerhetskopiering.<\/li>\n
    2. ett lagringsf\u00f6rr\u00e5d skapas p\u00e5 servern f\u00f6r s\u00e4kerhetskopiering, zbackup k\u00f6rs via ssh p\u00e5 servern f\u00f6r s\u00e4kerhetskopiering, som via ett pipe tar emot data.<\/li>\n<\/ol>\n

      <\/p>\n

      Resultaten fr\u00e5n den f\u00f6rsta varianten var f\u00f6ljande: 43m11s \u2014 vid anv\u00e4ndning av det okrypterade lagringsf\u00f6rr\u00e5det och kompressorn lzma, 19m13s \u2014 vid byte av kompressorn till lzo.<\/p>\n

      <\/p>\n

      Belastningen p\u00e5 servern med k\u00e4lldata var f\u00f6ljande (exemplet med lzma visas, med lzo var bilden ungef\u00e4r densamma, men andelen rsync var ungef\u00e4r en fj\u00e4rdedel av tiden):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Det \u00e4r tydligt att en s\u00e5dan s\u00e4kerhetskopieringsprocess endast \u00e4r l\u00e4mplig vid relativt s\u00e4llsynta och sm\u00e5 f\u00f6r\u00e4ndringar. Det \u00e4r ocks\u00e5 mycket \u00f6nskv\u00e4rt att begr\u00e4nsa zbackup till 1 tr\u00e5d, annars blir belastningen p\u00e5 processorn mycket h\u00f6g, eftersom programmet verkligen klarar av att arbeta i flera tr\u00e5dar. Diskbelastningen var liten, vilket i allm\u00e4nhet inte kommer att m\u00e4rkas med moderna diskundersystem baserade p\u00e5 ssd. Det \u00e4r ocks\u00e5 tydligt att starta synchroniseringsprocessen av lagringsf\u00f6rr\u00e5dets data till den fj\u00e4rrservern, hastigheten p\u00e5 arbetet \u00e4r j\u00e4mf\u00f6rbar med vanlig rsync och begr\u00e4nsas av prestandan hos diskundersystemet f\u00f6r s\u00e4kerhetskopieringsservern. En nackdel med metoden \u00e4r lagring av det lokala lagringsf\u00f6rr\u00e5det och, som en f\u00f6ljd, - duplicering av data.<\/p>\n

      <\/p>\n

      Det intressantare och mer praktiska alternativet \u00e4r det andra alternativet med att k\u00f6ra zbackup direkt p\u00e5 servern som lagrar s\u00e4kerhetskopior.<\/p>\n

      <\/p>\n

      F\u00f6rst kommer vi att kontrollera funktionen utan att anv\u00e4nda kryptering med kompressorn lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      K\u00f6rtiden f\u00f6r varje testk\u00f6rning:<\/p>\n

      <\/p>\n

      K\u00f6rning 1
      \nK\u00f6rning 2
      \nK\u00f6rning 3<\/p>\n

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

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

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

      <\/p>\n

      Om kryptering aktiveras med hj\u00e4lp av aes, \u00e4r resultaten tillr\u00e4ckligt n\u00e4ra:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      K\u00f6rtid med samma data, med kryptering:<\/p>\n

      <\/p>\n

      K\u00f6rning 1
      \nK\u00f6rning 2
      \nK\u00f6rning 3<\/p>\n

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

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

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

      <\/p>\n

      Om kryptering kombineras med komprimering p\u00e5 lzo, ser det ut s\u00e5 h\u00e4r:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Driftstid:<\/p>\n

      <\/p>\n

      K\u00f6rning 1
      \nK\u00f6rning 2
      \nK\u00f6rning 3<\/p>\n

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

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

      8m48s
      \n9m3s
      \nStorleken p\u00e5 det resulterande arkivet var relativt likartad och uppgick till 13 GB. Det betyder att deduplicering fungerar korrekt. Dessutom ger till\u00e4mpningen av lzo p\u00e5 redan komprimerade data en p\u00e5taglig effekt, och den totala k\u00f6rtiden f\u00f6r zbackup kommer n\u00e4ra duplicity\/duplicati, men ligger efter de som \u00e4r baserade p\u00e5 librsync med 2-5 g\u00e5nger.<\/p>\n

      <\/p>\n

      F\u00f6rdelarna \u00e4r uppenbara \u2014 besparing av diskutrymme p\u00e5 servern som lagrar s\u00e4kerhetskopior. N\u00e4r det g\u00e4ller verktyg f\u00f6r att kontrollera arkivet \u2014 \u00e4r de inte f\u00f6rsedda av f\u00f6rfattaren av zbackup, s\u00e5 det rekommenderas att anv\u00e4nda ett redundanta diskarray eller en molnleverant\u00f6r.<\/p>\n

      <\/p>\n

      \u00d6verlag ett ganska bra intryck, trots att projektet st\u00e5tt stilla i ungef\u00e4r 3 \u00e5r (senaste funktionsf\u00f6rfr\u00e5gan var f\u00f6r cirka ett \u00e5r sedan, men utan svar).<\/p>\n

      <\/p>\n

      Test av borgbackup<\/p>\n

      <\/p>\n

      Borgbackup \u00e4r en fork av attic, ett annat system som liknar zbackup. Skriven i python, har en liknande funktionslista som zbackup, men kan dessutom:<\/h3>\n

      <\/p>\n

      Montera s\u00e4kerhetskopior via fuse<\/p>\n

      <\/p>\n