Durée de vie et efficacité de la sauvegarde complète Duplicity

J'essaie d'élaborer une stratégie de sauvegarde pour certains clients et je penche vers la duplicité pour la sauvegarde à distance (utilisez déjà rdiff-backup pour les sauvegardes internes / sur site).

Est-il raisonnable de vouloir une sauvegarde complète de temps en temps? Étant donné que la duplicité s'incrémente vers l'avant, chaque sauvegarde incrémentielle s'appuie sur l'incrément précédent, et tous dépendent fortement de la dernière sauvegarde complète. Si cela devenait corrompu, de mauvaises choses se produisent. Une question connexe: Duplicity teste-t - il la cohérence des sauvegardes incrémentielles?

En supposant que je ne veux une sauvegarde complète tous si souvent, comment efficacement la duplicité créer cette sauvegarde complète? Peut-il / vérifie-t-il les signatures de fichiers et copie-t-il les données inchangées des sauvegardes / incréments complets précédents? Fondamentalement, créer une nouvelle archive «complète» transférant des données nouvelles / modifiées et fusionnant les données inchangées existantes?

Pour l'instant, je crains que l'exécution d'une sauvegarde complète soit nécessaire, mais l'utilisation cohérente d'une large bande passante des sauvegardes complètes rendra cela déraisonnable pour certains clients.

Je pense qu'il est raisonnable de vouloir une sauvegarde complète de temps en temps: la plupart de mes machines sont configurées pour en faire une tous les quelques mois. Ce nombre n'a rien de magique: la bonne valeur dépendra de la quantité de données dont vous disposez, de la vitesse à laquelle elles changent, de la probabilité que vous souhaitiez restaurer à partir d'autre chose que de l'instantané le plus récent, du trafic et du stockage qui vous coûtent et à quel point vous êtes paranoïaque. D'autres personnes peuvent souhaiter une sauvegarde complète chaque semaine.

Sauf si vous effectuez une sauvegarde complète de temps en temps, la taille de l'archive et le temps de récupération continueront d'augmenter.

Je ne pense pas que la duplicité ait spécifiquement une commande "check" http://pad.lv/660895 , mais ce serait bien si c'était le cas. Il est très prudent de faire un test de restauration de temps en temps.

Une question connexe est de savoir si vous devez conserver plusieurs chaînes de sauvegarde. Encore une fois, cela dépend du coût. Une raison pour en conserver une est que vous pouvez restaurer à partir de celle-ci si la chaîne actuelle est corrompue, soit en raison d'une défaillance matérielle, d'une défaillance du système d'exploitation ou d'un bogue de duplicité. Bien sûr, si l'ancienne chaîne est très ancienne, sa restauration peut avoir une valeur limitée.

Une sauvegarde complète télécharge toujours une copie complète des données.

Si la préoccupation du client est la fraction de la bande passante utilisée, plutôt que les frais de trafic, vous pouvez l'exécuter sous, par exemple trickle.

Ce que vous demandez est appelé une sauvegarde complète synthétique , qui fait référence au processus d'obtention d'une sauvegarde complète en fusionnant une sauvegarde incrémentielle avec une sauvegarde complète précédente du côté de la destination (c'est-à-dire: le serveur de sauvegarde).

Je ne connais pas Duplicity, mais à partir de leur site Web, il ne semble pas faire de sauvegardes complètes synthétiques. Vous devez conserver tous les incrémentaux dans leur intégralité. Si tel est le cas, vous voudrez probablement forcer une sauvegarde complète de temps en temps, car:

• Traverser un million d'incréments va probablement ralentir les restaurations
• Vous ne voulez probablement pas que les incrémentaux remontent au début des temps

Une façon intéressante d'obtenir des fulls synthétiques est d'utiliser rsync avec l'option --link-dest = DIR , ou d'utiliser rsnapshot . Il ne stockera que les différences entre chaque sauvegarde incrémentielle, mais chacune semblera pleine. Lorsque vous supprimez l' un d'eux, il fusionnera automatiquement les incrémentaux de manière appropriée. Il fait cela à travers la magie des liens durs, donc les diffs seront basés sur des fichiers (soit le fichier a changé et est inclus dans le diff, soit non).