{"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\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Backup, parte 4: Panoramica e test di zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

In questo articolo verranno considerati gli strumenti software per il backup, che, suddividendo il flusso di dati in componenti separate (chunks), formano un repository.<\/p>\n

<\/p>\n

I componenti del repository possono essere ulteriormente compressi e crittografati, e la cosa pi\u00f9 importante \u00e8 che, durante i processi di backup successivi, possano essere riutilizzati.<\/p>\n

<\/p>\n

Un backup in un simile repository \u00e8 una catena nominata di componenti correlati tra loro, ad esempio, basata su diverse funzioni hash.<\/p>\n

<\/p>\n

Esistono diverse soluzioni simili, mi concentrer\u00f2 su 3: zbackup, borgbackup e restic.<\/p>\n

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

Risultati attesi<\/h3>\n

<\/p>\n

Poich\u00e9 tutti i candidati richiedono in un modo o nell'altro la creazione di un repository, uno dei fattori pi\u00f9 importanti sar\u00e0 la valutazione delle dimensioni del repository. Idealmente, la sua dimensione non dovrebbe superare i 13 GB secondo la metodologia accettata, e ancor meno \u2014 a condizione di una buona ottimizzazione.<\/p>\n

<\/p>\n

Inoltre, \u00e8 estremamente desiderabile avere la possibilit\u00e0 di creare backup di file direttamente, senza l'uso di archivi come tar, e gestire ssh\/sftp senza strumenti aggiuntivi come rsync e sshfs.<\/p>\n

<\/p>\n

Comportamento nella creazione dei backup:<\/strong><\/p>\n

<\/p>\n

    \n
  1. La dimensione del repository sar\u00e0 pari alla dimensione delle modifiche, o minore.<\/li>\n
  2. Ci si aspetta un carico maggiore sulla CPU durante l'uso della compressione e\/o della crittografia, e potrebbe esserci un carico piuttosto elevato sulla rete e sul sottosistema di memorizzazione, se il processo di archiviazione e\/o crittografia avviene sul server di archiviazione dei backup.<\/li>\n
  3. Se il repository viene danneggiato, si potrebbe verificare un errore ritardato sia durante la creazione di nuovi backup, sia durante il tentativo di ripristino. \u00c8 necessario pianificare misure aggiuntive per garantire l'integrit\u00e0 del repository o utilizzare strumenti integrati di verifica della sua integrit\u00e0.<\/li>\n<\/ol>\n

    <\/p>\n

    Un valore di riferimento \u00e8 considerato il lavoro con tar, come mostrato in uno degli articoli precedenti.<\/p>\n

    <\/p>\n

    Test del zbackup<\/h3>\n

    <\/p>\n

    Il meccanismo generale di funzionamento di zbackup consiste nel fatto che il programma individua nel flusso di dati fornito in ingresso aree contenenti dati identici, poi le comprime e le crittografa opzionalmente, mantenendo ogni area solo una volta.<\/p>\n

    <\/p>\n

    Per la deduplicazione viene utilizzata una funzione hash circolare a 64 bit con una finestra scorrevole per il confronto byte per byte con i blocchi di dati gi\u00e0 esistenti (in modo simile a quanto realizzato in rsync).<\/p>\n

    <\/p>\n

    Per la compressione vengono utilizzati lzma e lzo in esecuzione multithread, mentre per la crittografia - aes. Nelle ultime versioni \u00e8 presente la possibilit\u00e0 di eliminare in futuro i vecchi dati dal repository.
    \nIl programma \u00e8 scritto in C++ con dipendenze minime. L'autore appare ispirato dal modo Unix, quindi il programma accetta i dati da stdin durante la creazione di backup, producendo un flusso di dati simile in stdout durante il ripristino. In questo modo, zbackup pu\u00f2 essere utilizzato come un valido \"mattoncino\" nella scrittura di soluzioni di backup personalizzate. Ad esempio, per l'autore dell'articolo, questo programma \u00e8 il principale strumento di backup per computer domestici dal 2014 circa.<\/p>\n

    <\/p>\n

    Come flusso di dati verr\u00e0 utilizzato un normale tar, se non diversamente specificato.<\/p>\n

    \nVediamo quali saranno i risultati:<\/b><\/p>\n

    Il test \u00e8 stato eseguito in 2 varianti:<\/p>\n

    <\/p>\n

      \n
    1. si crea un repository e si avvia zbackup su un server con i dati originali, poi il contenuto del repository viene trasferito su un server di archiviazione dei backup.<\/li>\n
    2. si crea un repository su un server di archiviazione dei backup, si avvia zbackup tramite ssh sul server di archiviazione dei backup e i dati vengono forniti tramite pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      I risultati del primo caso sono stati i seguenti: 43m11s - utilizzando un repository non crittografato e il compressore lzma, 19m13s - sostituendo il compressore con lzo.<\/p>\n

      <\/p>\n

      Il carico sul server con i dati originali \u00e8 stato il seguente (mostrata un esempio con lzma, con lzo \u00e8 stata ottenuta un'immagine simile, ma la quota di rsync \u00e8 stata circa un quarto del tempo):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      \u00c8 chiaro che un simile processo di backup \u00e8 adatto solo per modifiche relativamente rare e di piccole dimensioni. \u00c8 anche estremamente consigliabile limitare l'operazione di zbackup a 1 thread, altrimenti ci sar\u00e0 un carico elevato sulla CPU, poich\u00e9 il programma riesce a lavorare molto bene in pi\u00f9 thread. Il carico sul disco \u00e8 stato modesto, il che, in generale, con i moderni sistemi di archiviazione basati su SSD, sar\u00e0 impercettibile. \u00c8 anche evidente l'avvio del processo di sincronizzazione dei dati del repository sul server remoto, la velocit\u00e0 di lavoro \u00e8 paragonabile a quella del normale rsync e dipende dalla performance del sistema di archiviazione del server di backup. Un punto negativo dell'approccio \u00e8 la conservazione del repository locale e, di conseguenza, la duplicazione dei dati.<\/p>\n

      <\/p>\n

      Risulta pi\u00f9 interessante e pratico il secondo opzione con avvio di zbackup direttamente sul server di archiviazione dei backup.<\/p>\n

      <\/p>\n

      Per cominciare, verr\u00e0 controllato il funzionamento senza crittografia con il compressore lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di esecuzione di ciascun avvio di test:<\/p>\n

      <\/p>\n

      Avvio 1
      \nAvvio 2
      \nAvvio 3<\/p>\n

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

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

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

      <\/p>\n

      Se si attiva la crittografia usando aes, i risultati sono abbastanza simili:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di esecuzione sugli stessi dati, con crittografia:<\/p>\n

      <\/p>\n

      Avvio 1
      \nAvvio 2
      \nAvvio 3<\/p>\n

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

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

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

      <\/p>\n

      Se si combina la crittografia con la compressione su lzo, i risultati sono:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di esecuzione:<\/p>\n

      <\/p>\n

      Avvio 1
      \nAvvio 2
      \nAvvio 3<\/p>\n

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

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

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

      <\/p>\n

      La dimensione del repository risultante era relativamente uniforme e pari a 13 GB. Questo significa che la deduplicazione funziona correttamente. Inoltre, sull'insieme di dati gi\u00e0 compressi, l\u2019applicazione di lzo produce un effetto tangibile: il tempo totale di esecuzione di zbackup si avvicina a quello di duplicity\/duplicati, pur rimanendo in ritardo rispetto a soluzioni basate su librsync di 2-5 volte.<\/p>\n

      <\/p>\n

      I vantaggi sono evidenti: risparmio di spazio su disco sul server di archiviazione dei backup. Per quanto riguarda gli strumenti di verifica del repository, l'autore di zbackup non li prevede, si consiglia di utilizzare un array di dischi ridondanti o un fornitore cloud.<\/p>\n

      <\/p>\n

      In generale, un\u2019impressione abbastanza positiva, nonostante il progetto sia fermo da circa 3 anni (l'ultima richiesta di funzionalit\u00e0 \u00e8 stata inoltrata circa un anno fa, ma senza risposta).<\/p>\n

      <\/p>\n

      Testing di borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup \u00e8 un fork di attic, un'altra sistemazione simile a zbackup. Scritto in python, ha un elenco di funzionalit\u00e0 simile a zbackup, ma in aggiunta pu\u00f2:<\/p>\n

      <\/p>\n