{"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 esamineremo gli strumenti software per il backup che, suddividendo il flusso di dati in componenti distinti (chunks), creano un repository.<\/p>\n

<\/p>\n

I componenti del repository possono essere ulteriormente compressi e cifrati, e soprattutto, durante i processi di backup successivi, possono essere riutilizzati.<\/p>\n

<\/p>\n

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

<\/p>\n

Ci sono diverse soluzioni simili, mi soffermer\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 della dimensione del repository. In un caso ideale, la sua dimensione non dovrebbe superare i 13 GB secondo la metodologia adottata, o addirittura essere inferiore, a condizione di una buona ottimizzazione.<\/p>\n

<\/p>\n

\u00c8 molto utile avere la possibilit\u00e0 di creare backup dei file direttamente, senza l'uso di archiviatori come tar, e di lavorare con ssh\/sftp senza strumenti aggiuntivi come rsync e sshfs.<\/p>\n

<\/p>\n

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

<\/p>\n

    \n
  1. La dimensione del repository sar\u00e0 equivalente alla dimensione delle modifiche, o inferiore.<\/li>\n
  2. \u00c8 prevista un'alta pressione sulla CPU quando si utilizza la compressione e\/o la crittografia, e ci si aspetta un carico significativo anche sulla rete e sul sistema di archiviazione, se il processo di archiviazione e\/o crittografia avviene sul server dei backup.<\/li>\n
  3. Se il repository viene danneggiato, \u00e8 probabile che si verifichino errori ritardati sia durante la creazione di nuovi backup che nel tentativo di ripristino. \u00c8 necessario pianificare ulteriori misure per garantire l'integrit\u00e0 del repository o utilizzare strumenti integrati per verificarne l'integrit\u00e0.<\/li>\n<\/ol>\n

    <\/p>\n

    Come valore di riferimento, \u00e8 stata utilizzata l'operazione con tar, come dimostrato in uno dei precedenti articoli.<\/p>\n

    <\/p>\n

    Test di zbackup<\/h3>\n

    <\/p>\n

    Il meccanismo generale di funzionamento di zbackup consiste nel trovare nel flusso di dati in ingresso aree contenenti dati identici, cos\u00ec da compattarle, crittografarle e conservarle ciascuna una sola volta.<\/p>\n

    <\/p>\n

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

    <\/p>\n

    Per la compressione si utilizzano lzma e lzo in esecuzione multithreading, mentre per la crittografia si utilizza aes. Nelle versioni pi\u00f9 recenti \u00e8 presente la possibilit\u00e0 di eliminare in futuro i dati obsoleti dal repository.
    \nIl programma \u00e8 scritto in C++ con dipendenze minime. L'autore sembra ispirarsi all'unix-way, quindi il programma legge i dati da stdin durante la creazione di backup, restituendo un flusso di dati simile su stdout durante il ripristino. In questo modo, zbackup pu\u00f2 essere utilizzato come un ottimo \"mattoncino\" per scrivere le proprie soluzioni di backup. Ad esempio, per l'autore dell'articolo, questo programma \u00e8 il principale strumento di backup per macchine domestiche dal 2014.<\/p>\n

    <\/p>\n

    Come flusso di dati verr\u00e0 utilizzato il comune tar, salvo indicazioni contrarie.<\/p>\n

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

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

    <\/p>\n

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

      <\/p>\n

      I risultati della prima modalit\u00e0 sono stati: 43m11s \u2014 utilizzando un repository non crittografato e il compressore lzma, 19m13s \u2014 sostituendo il compressore con lzo.<\/p>\n

      <\/p>\n

      Il carico sul server con i dati originali \u00e8 stato il seguente (incluso un esempio con lzma; con lzo era simile, ma la parte di rsync era circa un quarto del tempo):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      \u00c8 chiaro che un processo di backup del genere \u00e8 adatto solo per modifiche relativamente rare e ridotte. \u00c8 anche fortemente consigliato limitare l'operazione di zbackup a un solo thread, altrimenti si avr\u00e0 un carico CPU piuttosto elevato, dato che il programma lavora molto bene in pi\u00f9 thread. Il carico sul disco \u00e8 stato ridotto, il che in generale non sar\u00e0 percepito con i moderni sistemi di archiviazione basati su SSD. \u00c8 evidente inoltre il lancio del processo di sincronizzazione dei dati del repository su un server remoto, e la velocit\u00e0 \u00e8 comparabile a quella del normale rsync, limitandosi quindi alle prestazioni del sistema di archiviazione dei backup. Uno svantaggio di questo approccio \u00e8 la conservazione del repository locale e, di conseguenza, la duplicazione dei dati.<\/p>\n

      <\/p>\n

      Un'opzione pi\u00f9 interessante e praticabile \u00e8 la seconda, che prevede l'esecuzione di zbackup direttamente sul server di archiviazione dei backup.<\/p>\n

      <\/p>\n

      Per iniziare, verr\u00e0 verificato il funzionamento senza l'uso della crittografia con il compressore lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di esecuzione di ciascun avvio di prova:<\/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 utilizzando aes, i risultati sono abbastanza simili:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di lavoro con gli 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 lzo, otteniamo:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Tempo di lavoro:<\/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 \u00e8 stata relativamente costante ed \u00e8 stata di 13 GB. Questo significa che la deduplicazione funziona correttamente. Inoltre, sull'archiviazione gi\u00e0 compressa, l'applicazione di lzo offre un effetto significativo, avvicinando il tempo totale di esecuzione di zbackup a quello di duplicity\/duplicati, anche se rimane indietro rispetto a quelli basati su librsync di 2-5 volte.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      In generale, una buona impressione, nonostante il fatto che il progetto sia fermo da circa 3 anni (l'ultima richiesta di funzionalit\u00e0 risale a circa un anno fa, ma senza risposta).<\/p>\n

      <\/p>\n

      Test di borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup \u00e8 un fork di attic, un altro sistema simile a zbackup. Scritto in Python, ha un elenco di funzionalit\u00e0 simili a quelle di zbackup, ma offre anche:<\/p>\n

      <\/p>\n