Ensuite dire qu'avoir une « image locale » [1] n'apporte aucune économie, est un "surcoût" pur et n'a absolument aucun impact dans le contexte du risque, c'est aussi très réducteur.
Ca me semble parfaitement exact. Pour tous les risques non couverts par ton "cache" tu dois garder EXACTEMENT la même stratégie tu ne peux faire aucune économie. Comme ton "cache local" ne gère qu'un petit sous ensemble de cas (peut-être très fréquents) en pratique c'est bien un surcout (pour possiblement une plus grande souplesse dans les cas les moins graves).
Pour avoir exactement la même fonctionnalité (nombre et fréquence des sauvegardes sur mon serveur distant) sans « cache de sauvegarde », je devrais investir beaucoup plus dans mon réseau. Est-ce que donc ce n'est pas une économie de procéder de la sorte ? Pour moi si.
En fait tu attends quoi de ce post ?
Que quelqu'un te dise que tu as découvert un truc fou ? Alors c'est aussi disruptif qu'un "rsync --link-dest" local, soit quelques décennies
J'aurais aimé deux choses :
Comprendre pourquoi ce genre de question provoque des réactions aussi extrêmes, brutales et parfois hystériques (après tout c'est une question technique, pas à propos de la politique ou sur la religion)
Avoir un débat plus orienté technique que rhétorique/philosophique parce que je trouve que les process de snapshots/send/receive et de déduplication et détection de corruption de données de Btrfs/ZFS sont très intéressants. Mais apparemment tout ce potentiel peut se résumer à "rsync --link-dest".
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Pour avoir exactement la même fonctionnalité (nombre et fréquence des sauvegardes sur mon serveur distant) sans « cache de sauvegarde », je devrais investir beaucoup plus dans mon réseau. Est-ce que donc ce n'est pas une économie de procéder de la sorte ? Pour moi si.
J'aurais aimé deux choses :