{"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\/nl\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Back-up, deel 4: Overzicht en testen van zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Back-up,<\/p>\n

<\/p>\n

In dit artikel worden softwaretools voor back-up besproken die door het splitsen van datastromen in afzonderlijke componenten (chunks) een repository vormen.<\/p>\n

<\/p>\n

De componenten van de repository kunnen bovendien worden gecomprimeerd en versleuteld, en het belangrijkste is dat ze bij herhaalde back-upprocessen opnieuw kunnen worden gebruikt.<\/p>\n

<\/p>\n

Een back-up in een dergelijke repository is een benoemde keten van met elkaar verbonden componenten, bijvoorbeeld op basis van verschillende hash-functies.<\/p>\n

<\/p>\n

Er zijn verschillende oplossingen, ik zal me richten op drie: zbackup, borgbackup en restic.<\/p>\n

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

Verwachte resultaten<\/h3>\n

<\/p>\n

Aangezien alle kandidaten op de een of andere manier vereisen dat er een repository wordt aangemaakt, is een van de belangrijkste factoren de beoordeling van de grootte van de repository. Idealiter zou de grootte niet meer dan 13 GB moeten zijn volgens de gehanteerde methode, en misschien zelfs minder \u2013 mits goed geoptimaliseerd.<\/p>\n

<\/p>\n

Het is ook uiterst wenselijk om de mogelijkheid te hebben om bestanden rechtstreeks te back-uppen, zonder gebruik te maken van archiveringshulpmiddelen zoals tar, evenals werken met ssh\/sftp zonder extra middelen zoals rsync en sshfs.<\/p>\n

<\/p>\n

Gedrag bij het maken van back-ups:<\/strong><\/p>\n

<\/p>\n

    \n
  1. De grootte van de repository zal gelijk zijn aan de grootte van de wijzigingen, of kleiner.<\/li>\n
  2. Er wordt een hoge belasting van de CPU verwacht bij gebruik van compressie en\/of versleuteling, en er kan ook een aanzienlijke belasting op het netwerk en de schijfsubsystemen zijn als het archiverings- en\/of versleutelingsproces op de back-upserver draait.<\/li>\n
  3. Als de repository beschadigd raakt, kan er een vertraagde fout optreden bij zowel het maken van nieuwe back-ups als bij pogingen tot herstel. Het is noodzakelijk om extra maatregelen te plannen voor het waarborgen van de integriteit van de repository of gebruik te maken van ingebouwde tools voor het controleren van de integriteit.<\/li>\n<\/ol>\n

    <\/p>\n

    Als referentiewaarde is het werken met tar aangenomen, zoals aangetoond in een van de vorige artikelen.<\/p>\n

    <\/p>\n

    Testen van zbackup<\/h3>\n

    <\/p>\n

    Het algemene werkmechanisme van zbackup is dat het programma gelijke gegevens in de inkomende datastroom vindt, vervolgens optioneel comprimeert en versleutelt, en elke gebied slechts \u00e9\u00e9n keer opslaat.<\/p>\n

    <\/p>\n

    Voor deduplicatie wordt een 64-bits ringhashfunctie met een glijdend venster gebruikt om byte-per-byte te controleren op overeenkomsten met reeds bestaande datablocks (vergelijkbaar met wat in rsync is ge\u00efmplementeerd).<\/p>\n

    <\/p>\n

    Voor compressie worden lzma en lzo in multithreading gebruikt, en voor versleuteling - aes. In de laatste versies is het mogelijk om in de toekomst oude gegevens uit het repository te verwijderen.
    \nHet programma is geschreven in C++ met minimale afhankelijkheden. De auteur lijkt ge\u00efnspireerd door de unix-structuur, daarom accepteert het programma gegevens via stdin bij het maken van back-ups, en levert het een vergelijkbare gegevensstroom naar stdout bij herstel. Op deze manier kan zbackup worden gebruikt als een zeer goede 'bouwsteen' bij het schrijven van eigen back-upoplossingen. Bijvoorbeeld, voor de auteur van het artikel is dit programma sinds ongeveer 2014 het belangrijkste hulpmiddel voor back-up van thuiscomputers.<\/p>\n

    <\/p>\n

    Als gegevensstroom wordt gewoonlijk tar gebruikt, tenzij anders aangegeven.<\/p>\n

    \nLaten we kijken wat de resultaten zullen zijn:<\/b><\/p>\n

    De werking is getest in 2 varianten:<\/p>\n

    <\/p>\n

      \n
    1. er wordt een repository aangemaakt en zbackup wordt uitgevoerd op de server met de oorspronkelijke gegevens, vervolgens wordt de inhoud van de repository overgedragen naar de back-upserver.<\/li>\n
    2. er wordt een repository aangemaakt op de back-upserver, zbackup wordt via ssh op de back-upserver uitgevoerd, waarbij gegevens via een pipe worden aangeleverd.<\/li>\n<\/ol>\n

      <\/p>\n

      De resultaten van de eerste variant waren als volgt: 43m11s - bij het gebruik van een niet-ge\u00ebncrypteerd repository en lzma-compressor, 19m13s - bij vervanging van de compressor door lzo.<\/p>\n

      <\/p>\n

      De belasting op de server met de originele gegevens was als volgt (hier een voorbeeld met lzma, met lzo was het ongeveer hetzelfde, maar het aandeel van rsync was ongeveer een kwart van de tijd):<\/p>\n

      <\/p>\n

      \"Back-up,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Het is duidelijk dat dit soort back-up processen slechts geschikt is bij relatief zeldzame en kleine wijzigingen. Het is ook uiterst wenselijk om de werking van zbackup te beperken tot 1 thread, anders zal de CPU belast zijn, omdat het programma zeer goed kan werken met meerdere threads. De belasting op de schijf was gering, wat over het algemeen met moderne schijfsystemen op basis van ssd niet merkbaar zal zijn. Het is ook duidelijk te zien dat het proces van gegevenssynchronisatie van de repository naar de externe server is gestart, en de snelheid van werken is vergelijkbaar met gewone rsync en is afhankelijk van de prestaties van het schijfsysteem van de back-upserver. Een nadeel van deze aanpak is het opslaan van een lokale repository en, als gevolg daarvan, de duplicatie van gegevens.<\/p>\n

      <\/p>\n

      De tweede optie, waarbij zbackup direct op de opslagserver voor back-ups wordt gestart, is interessanter en praktischer toepasbaar.<\/p>\n

      <\/p>\n

      We beginnen met het testen zonder versleuteling met de lzma-compressor:<\/p>\n

      <\/p>\n

      \"Back-up,<\/a><\/noindex><\/p>\n

      <\/p>\n

      De uitvoeringstijd van elke testuitvoering:<\/p>\n

      <\/p>\n

      Uitvoering 1
      \nUitvoering 2
      \nUitvoering 3<\/p>\n

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

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

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

      <\/p>\n

      Wanneer we versleuteling met aes inschakelen, zijn de resultaten behoorlijk vergelijkbaar:<\/p>\n

      <\/p>\n

      \"Back-up,<\/a><\/noindex><\/p>\n

      <\/p>\n

      De uitvoeringstijd op dezelfde gegevens, met encryptie:<\/p>\n

      <\/p>\n

      Uitvoering 1
      \nUitvoering 2
      \nUitvoering 3<\/p>\n

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

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

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

      <\/p>\n

      Wanneer we versleuteling combineren met compressie met lzo, zien we het volgende:<\/p>\n

      <\/p>\n

      \"Back-up,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Looptijd:<\/p>\n

      <\/p>\n

      Uitvoering 1
      \nUitvoering 2
      \nUitvoering 3<\/p>\n

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

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

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

      <\/p>\n

      De grootte van de resulterende repository was grotendeels constant op 13GB. Dit betekent dat deduplicatie correct werkt. Ook geeft het toepassen van lzo op reeds gecomprimeerde gegevens een merkbaar effect, en de totale tijd die zbackup verbruikt, nadert die van duplicity\/duplicati, maar blijft 2-5 keer achter bij oplossingen die gebaseerd zijn op librsync.<\/p>\n

      <\/p>\n

      De voordelen zijn duidelijk \u2013 besparing van schijfruimte op de opslagserver voor back-ups. Wat betreft de middelen voor het controleren van de repository \u2013 deze zijn niet voorzien door de auteur van zbackup, dus het wordt aanbevolen gebruik te maken van een redundant schijfsysteem of cloudprovider.<\/p>\n

      <\/p>\n

      Algemeen genomen een heel goede indruk, hoewel het project inmiddels ongeveer 3 jaar stil staat (de laatste feature request was ongeveer een jaar geleden, maar zonder reactie).<\/p>\n

      <\/p>\n

      Testen van borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup is een fork van attic, een ander systeem dat lijkt op zbackup. Het is geschreven in Python en heeft een vergelijkbare set functies als zbackup, maar kan bovendien:<\/p>\n

      <\/p>\n