{"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\/da\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Sikkerhedskopiering, del 4: Oversigt og test af zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sikkerhedskopiering,<\/p>\n

<\/p>\n

I denne artikel vil vi se p\u00e5 softwarev\u00e6rkt\u00f8jer til sikkerhedskopiering, der ved at opdele datastreamen i separate komponenter (chunks) danner et repository.<\/p>\n

<\/p>\n

Repository-komponenter kan yderligere komprimeres og krypteres, og vigtigst af alt \u2013 ved gentagne sikkerhedskopieringsprocesser \u2013 genbruges.<\/p>\n

<\/p>\n

En sikkerhedskopi i et s\u00e5dant repository er en navngivet k\u00e6de af relaterede komponenter, f.eks. baseret p\u00e5 forskellige hash-funktioner.<\/p>\n

<\/p>\n

Der er flere s\u00e5danne l\u00f8sninger, jeg vil fokusere p\u00e5 3: zbackup, borgbackup og restic.<\/p>\n

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

Forventede resultater<\/h3>\n

<\/p>\n

Da alle kandidater p\u00e5 en eller anden m\u00e5de kr\u00e6ver oprettelse af et repository, vil en af de vigtigste faktorer v\u00e6re vurderingen af repositoryets st\u00f8rrelse. Ideelt set b\u00f8r dets st\u00f8rrelse ikke overstige 13 GB if\u00f8lge den anerkendte metode, og gerne mindre \u2013 under foruds\u00e6tning af god optimering.<\/p>\n

<\/p>\n

Det er ogs\u00e5 yderst \u00f8nskeligt at have mulighed for at lave sikkerhedskopier af filer direkte, uden at anvende arkiveringsprogrammer som tar, samt at arbejde med ssh\/sftp uden yderligere v\u00e6rkt\u00f8jer som rsync og sshfs.<\/p>\n

<\/p>\n

Adf\u00e6rd ved sikkerhedskopiering:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Repositoryets st\u00f8rrelse vil v\u00e6re lig med st\u00f8rrelsen af \u00e6ndringerne, eller mindre.<\/li>\n
  2. Der forventes en stor belastning p\u00e5 CPU'en ved brug af komprimering og\/eller kryptering, og der kan ogs\u00e5 v\u00e6re en betydelig belastning p\u00e5 netv\u00e6rket og diskSubsystemet, hvis arkiverings- og\/eller krypteringsprocessen k\u00f8rer p\u00e5 serveren til sikkerhedskopiering.<\/li>\n
  3. Hvis repositoryet bliver beskadiget \u2013 er der risiko for forsinkede fejl b\u00e5de ved oprettelse af nye sikkerhedskopier og ved fors\u00f8g p\u00e5 at gendanne. Man skal planl\u00e6gge ekstra foranstaltninger for at sikre repositoryets integritet eller bruge indbyggede v\u00e6rkt\u00f8jer til at kontrollere dets integritet.<\/li>\n<\/ol>\n

    <\/p>\n

    Som referencev\u00e6rdien er der arbejdet med tar, som vist i en af de tidligere artikler.<\/p>\n

    <\/p>\n

    Test af zbackup<\/h3>\n

    <\/p>\n

    Den overordnede funktion af zbackup er, at programmet finder omr\u00e5der i datastreamen, der sendes ind, som indeholder de samme data, og derefter komprimerer og krypterer dem valgfrit, idet hver omr\u00e5de kun gemmes \u00e9n gang.<\/p>\n

    <\/p>\n

    Til deduplikation anvendes en 64-bit ringhash-funktion med et glidende vindue til byte-for-byte kontrol af match med allerede eksisterende datablokke (svarende til hvad der er implementeret i rsync).<\/p>\n

    <\/p>\n

    Til kompression anvendes lzma og lzo i en multitr\u00e5det udf\u00f8relse, mens kryptering benytter aes. I de seneste versioner er der mulighed for i fremtiden at slette gamle data fra depotet.
    \nProgrammet er skrevet i C++ med minimale afh\u00e6ngigheder. Forfatteren ser ud til at v\u00e6re inspireret af Unix-tilgangen, da programmet modtager data via stdin ved oprettelse af sikkerhedskopier og leverer en lignende datastream til stdout ved gendannelse. P\u00e5 denne m\u00e5de kan zbackup bruges som en ganske god «brik» til at skrive egne sikkerhedskopieringsl\u00f8sninger. For eksempel har forfatteren af artiklen brugt dette program som det prim\u00e6re sikkerhedskopieringsv\u00e6rkt\u00f8j til hjemmecomputere siden omkring 2014.<\/p>\n

    <\/p>\n

    Som datastream anvendes almindelig tar, medmindre andet er angivet.<\/p>\n

    \nLad os se, hvad resultaterne bliver:<\/b><\/p>\n

    Testen blev udf\u00f8rt i 2 varianter:<\/p>\n

    <\/p>\n

      \n
    1. et depot oprettes, og zbackup k\u00f8res p\u00e5 serveren med de originale data, hvorefter indholdet af depotet overf\u00f8res til backup-lagringsserveren.<\/li>\n
    2. et depot oprettes p\u00e5 backup-lagringsserveren, zbackup k\u00f8res via ssh p\u00e5 backup-lagringsserveren, hvor data gives til det gennem en pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Resultaterne af den f\u00f8rste variant var som f\u00f8lger: 43m11s \u2014 ved brug af et ukrypteret depot og kompressoren lzma, 19m13s \u2014 ved at erstatte kompressoren med lzo.<\/p>\n

      <\/p>\n

      Belastningen p\u00e5 serveren med de originale data var som f\u00f8lger (her vises et eksempel med lzma, med lzo var billedet omtrent det samme, men andelen af rsync var cirka en fjerdedel af tiden):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Det er klart, at en s\u00e5dan backup-proces kun er velegnet til relativt sj\u00e6ldne og sm\u00e5 \u00e6ndringer. Det er ogs\u00e5 meget \u00f8nskeligt at begr\u00e6nse zbackup's arbejde til 1 tr\u00e5d, ellers vil CPU-belastningen v\u00e6re meget h\u00f8j, da programmet er meget godt til at arbejde med flere tr\u00e5de. Belastningen p\u00e5 disken var lille, hvilket generelt vil v\u00e6re usynligt med moderne diskunderst\u00f8ttelse baseret p\u00e5 SSD. Det er ogs\u00e5 tydeligt at se lanceringen af synchroniseringsprocessen af datalageret til den fjernserver, og hastigheden ligner den almindelige rsync og er begr\u00e6nset af ydeevnen af diskunderst\u00f8ttelsen i backup-serveren. Ulempen ved denne tilgang er, at den lokale repository skal opbevares, og som f\u00f8lge heraf \u2014 datadublisering.<\/p>\n

      <\/p>\n

      Den mere interessante og praktisk anvendelige mulighed er den anden variant med at starte zbackup direkte p\u00e5 backup-serveren.<\/p>\n

      <\/p>\n

      For at starte vil der blive tjekket arbejde uden brug af kryptering med lzma-komprimering:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tid for hver teststart:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

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

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

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

      <\/p>\n

      Hvis man aktiverer kryptering ved hj\u00e6lp af aes, er resultaterne ret t\u00e6t p\u00e5:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tid for arbejde med de samme data, med kryptering:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

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

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

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

      <\/p>\n

      Hvis kryptering kombineres med komprimering ved hj\u00e6lp af lzo, bliver det s\u00e5dan:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tid for arbejde:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

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

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

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

      <\/p>\n

      St\u00f8rrelsen p\u00e5 det resulterende repository var relativt ens og udgjorde 13 GB. Dette betyder, at deduplikeringsprocessen fungerer korrekt. Desuden giver anvendelsen af lzo p\u00e5 allerede komprimerede data en betydelig effekt; den samlede arbejdstid for zbackup er n\u00e6rmere duplicity\/duplicati, men er 2-5 gange langsommere end dem baseret p\u00e5 librsync.<\/p>\n

      <\/p>\n

      Fordelene er \u00e5benlyse \u2014 besparelse af diskplads p\u00e5 backup-serveren. Hvad ang\u00e5r v\u00e6rkt\u00f8jerne til at kontrollere repository \u2014 disse er ikke forudset af zbackup-forfatterne; det anbefales at bruge et fejltolerant diskarray eller en cloud-udbyder.<\/p>\n

      <\/p>\n

      Generelt et ret godt indtryk, p\u00e5 trods af at projektet har st\u00e5et stille i cirka 3 \u00e5r (den seneste feature request var for omkring et \u00e5r siden, men uden svar).<\/p>\n

      <\/p>\n

      Testning af borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup er en fork af attic, endnu et system, der ligner zbackup. Det er skrevet i Python og har en lignende funktionsliste som zbackup, men kan desuden:<\/p>\n

      <\/p>\n