Durata ed efficienza del backup completo di Duplicity

Sto cercando di elaborare una strategia di backup per alcuni client e mi sto impegnando per la duplicità per il backup remoto (già uso rdiff-backup per backup interni / in loco).

È ragionevole desiderare un backup completo ogni tanto? Poiché gli incrementi di duplicità in avanti, ogni backup incrementale si basa sull'incremento precedente e tutti si basano fortemente sull'ultimo backup completo. Se dovesse diventare corrotto, accadere cose brutte. Una domanda correlata: Duplicity verifica la coerenza dei backup incrementali?

Supponendo che io non voglio un backup completo ogni tanto, come in modo efficiente non doppiezza creare l'backup completo? Può / controlla le firme dei file e copia i dati invariati da backup / incrementi completi precedenti? Fondamentalmente creando un nuovo archivio "completo" trasferendo dati nuovi / modificati e unendo i dati invariati esistenti?

In questo momento la mia preoccupazione è che sia necessario eseguire un backup completo, ma l'uso consistente della larghezza di banda dei backup completi renderà irragionevole per alcuni client.

Penso che sia ragionevole desiderare un backup completo ogni tanto: la maggior parte delle mie macchine sono configurate per eseguirne uno ogni pochi mesi. Non c'è nulla di magico in quel numero: il valore giusto dipenderà da quanti dati hai, quanto velocemente cambia, quanto è probabile che tu voglia ripristinare da qualcosa di diverso dall'istantanea più recente, quanto ti costa il traffico e lo spazio di archiviazione e quanto sei paranoico. Altre persone potrebbero desiderare un backup completo ogni settimana.

A meno che non si esegua un backup completo di volta in volta, le dimensioni dell'archivio e il tempo di ripristino continueranno a crescere.

Non credo che la duplicità abbia specificamente un comando "check" http://pad.lv/660895 , ma sarebbe bello se lo facesse. È molto prudente eseguire un ripristino di prova ogni tanto.

Una domanda correlata è se è necessario conservare più di una catena di backup. Ancora una volta, dipende dal costo. Uno dei motivi per mantenerne uno è che è possibile ripristinare da esso se la catena corrente è danneggiata, a causa di un errore hardware, errore del sistema operativo o un bug di duplicità. Naturalmente se la vecchia catena è molto vecchia, ripristinarla può avere un valore limitato.

Effettuare un backup completo carica sempre una copia completa dei dati.

Se la preoccupazione del cliente è la frazione di larghezza di banda utilizzata, piuttosto che i diritti di traffico, potresti volerlo eseguire ad es trickle.

Quello che si sta chiedendo è chiamato backup completo sintetico , che si riferisce al processo per ottenere un backup completo unendo un backup incrementale con un backup completo precedente sul lato di destinazione (ad esempio: il server di backup).

Non ho familiarità con Duplicity, ma dal loro sito web sembra non fare backup completi sintetici. È necessario mantenere tutti gli incrementali al massimo su cui si basano. Se questo è il caso, probabilmente si vuole forzare un backup completo ogni tanto, in quanto:

• Passare attraverso un milione di incrementi probabilmente rallenta i ripristini
• Probabilmente non vorrai mantenere gli incrementali risalenti all'inizio del tempo

Un modo interessante per ottenere i full sintetici è usare rsync con l'opzione --link-dest = DIR , oppure usare rsnapshot . Memorizzerà solo le differenze tra ciascun backup incrementale, ma ognuna sembrerà piena. Quando ne elimini uno , unirà automaticamente gli incrementali in modo appropriato. Lo fa attraverso la magia di hard link, quindi i diff saranno basati su file (o il file è cambiato ed è incluso nel diff, oppure no).