Kevin Kofler (./3942) :
Il suffit de sauvegarder moins souvent que la durée de la sauvegarde. Si on estime que la sauvegarde durera 10 ms au maximum, on sauvegarde toutes les 60 secondes et on est tranquille.

Bonjour "Monsieur je ne sais pas comment ça se passe dans la vie active"...
Quand on définit une politique de sauvegarde, celle-ci est bien souvent déterminée pour plusieurs années (une architecture de sauvegarde digne de ce nom a un coût assez impressionnant, en général on l'amortit dur 3 à 5 ans) ; il faut donc
- anticiper les dimensionnements (c'est moins pour l'espace disque - qui peut en général assez facilement s'étendre, sauf quand on parle de sauvegarde sur bandes et que le robot a une queue limitée - que pour la durée de la sauvegarde, afin d'éviter que plusieurs sauvegardes de systèmes différents ne se télescopent et ne créent des décalages dans la file d'attente)
- anticiper les fonctionnements non prévus (la sauvegarde, c'est un élément critique du système qui a cette particularité de ne devenir critique que quand on en a besoin ; on doit donc s'assurer qu'elle va bien fonctionner même si on n'en vérifie pas le bon fonctionnement tous les jours, son déroulement devant être le plus transparent par l'utilisateur) : a minima, prévoir un système complémentaire en cas de débordement de capacité (temps et espace disque) qui permette de se dégager du temps pour trouver une extension propre du système arrivé au bout de ses limites, et avoir une politique de priorisation ou de parallélisation lorsque deux processus de sauvegarde doivent démarrer de façon concomitante (la politique va dépendre de la technologie utilisée : on ne fait pas les mêmes choix sur bandes, sur disque, ou sur bande+disque).

En outre, ton analyse ne prend pas en compte les problématiques de réplication (ce pourquoi BerkeleyDB est énormément utilisé dans des systèmes où on a besoin de réplications, comme les annuaires LDAP) : plusieurs systèmes esclaves peuvent demander une synchronisation avec le parent alors que la synchronisation du précédent n'est pas terminée. Dans ce cas là, hors de question de dire au second esclave "t'attends encore une heure, tu auras tes données quand j'aurai fini". Le système doit pouvoir proposer une solution (pour BDB, les logs transactionnels sont archivés sans limite sauf opération de maintenance, et l'esclave demande tous les logs depuis le dernier point de synchro ; lorsqu'on purge les logs transactionnels, il faut s'assurer que tous les esclaves sont à jour - mais on peut aussi purger ces fichiers de log jusqu'à un point donné pour s'octroyer une marge de sécurité... on peut estimer, par exemple, qu'un esclave qui n'est pas synchrone depuis plus de n jours est en erreur et qu'il sera plus efficace de refaire une synchro totale par copie des données via une dump de la base qu'une synchro partielle).
Alors c'est sûr qu'on travaille très vite sur de très gros volumes de données (les logs transactionnels montent très vite en taille).