Là on est à peu près d'accord ton « cache de sauvegarde » te permet d'opérer localement, mais de la même manière qu'un dépôt local git n'est même pas un dépôt de référence pour collaborer [...] puisque "bosser seul" n'est qu'un cas particulier de "bosser" [...] ton « cache de sauvegarde » est un cache de la sauvegarde, pas la sauvegarde.
On touche aux limites de l'analogie car il faut justement se placer dans le cas où tu bosses seul (je ne fais pas de sauvegarde collaborative, quoique ce serait un sujet intéressant). Mais disons que je souhaite avoir mon dépôt aussi sur Github, pour une raison quelconque (utiliser les beaux outils de Github par exemple, bon c'est peut-être foireux).
Entre ton dépôt local que tu mets à jour toutes les 5 minutes et le dépôt Github sur lequel tu pushes tous les jours, lequel est alors la référence de ton point de vue ?
De mon point de vue les deux sont strictement identiques en fin de journée, donc en fin de journée les deux sont la référence.
Ou alors, pour nuancer un peu et reprendre un argument déjà mis plus haut, c'est une sauvegarde qui répond à un modèle de menace extrêmement ténu [...]. C'est déjà ça, mais c'est très très faible comme risques couverts, surtout vu la relative facilité d'en couvrir beaucoup plus avec un stockage distant.
Disons que si j'avais une fibre de folie, le fonctionnement serait parfaitement symétrique : je sauvegarderai en permanence sur le serveur distant et de temps en temps je téléchargerai une copie du serveur distant en local (au cas où le serveur tomberait en panne).
Mais sans cette fibre de folie, ce n'est pas « relativement facile d'en couvrir plus avec le stockage distant », c'est juste presque impossible car mon « modèle de menace extrêmement ténu » (erreur de l'utilisateur) est celui qui m'arrive le plus et celui contre quoi je souhaite vraiment me protéger efficacement (et sauvegarder sur un serveur distant, c'est tout sauf efficace).
Donc pour moi c'est comme un dépôt local qui permet de faire ses bidouilles proprement et localement, et ensuite synchroniser le tout vers le dépôt distant quand on le veut.
Attention ça sonnerait presque comme "je prépare ma sauvegarde en local et je la fais effectivement lorsque je l'envoie à distance" :-)
Oui c'est presque exactement ça. À la différence que je restaure aussi à partir de mon « cache de sauvegarde » (qui est de fait toujours beaucoup plus à jour que la « sauvegarde distante »).
Je veux bien une analyse de texte argumentée qui me contredit, mais pour moi (et pas que moi vus les commentaires à ce sujet) c'est vraiment une phrase structurée comme "on me dit qu'il ne faut pas faire confiance au CoW, qu'il faut backup à distance pour se prémunir de ses défaillances, mais j'ai pas forcément besoin de cette copie distante, puisque j'ai le RAID1".
Pas de soucis, si tu le permets voici la citation exacte :
Là où je doute un peu de mon système, c'est que [...] en pratique il n'y a qu'une copie physique de chaque donnée (deux copies en fait car mon disque est en RAID1 pour éviter les corruptions de données ou bit rot). Je fais donc confiance à fond au Copy-on-Write (CoW) pour ne pas détruire ma sauvegarde au cas où je fais une bêtise avec la donnée d'origine. Là aussi on me traite d'hérétique de faire confiance au CoW et qu'il faut absolument une copie/duplication physique pour « sécuriser » la donnée de manière sûre (la copie qui est dû au RAID1 ne compte apparemment pas).
Je n'ai pas changé grand chose dans la structure, mais est-ce que c'est plus clair comme cela :
Donc je doute de mon système car en pratique il n'y a qu'une copie ce qui fait que je fais confiance à fond au CoW pour ne pas la détruire.
On me dit qu'il ne faut pas faire confiance au CoW et qu'il faut une copie physique pour « sécuriser » car la copie du RAID1 ne compte apparemment pas.
Sinon reformulé différemment :
Je n'ai pas confiance dans mon système car je fais trop confiance au CoW car je n'ai qu'une copie de la donnée (en effet même si mon disque est en RAID1, l'autre copie du RAID1 n'est en pratique là que pour corriger le bit rot).
On me déconseille cependant de faire confiance au CoW et on me conseille de faire une autre copie non-CoW de la donnée pour la « sécuriser » (l'autre copie du RAID1 n'est apparemment pas valable pour « sécuriser » la donnée).
Ou bien encore, formulé dans un style plus brut de fonderie et moins littéraire. Étant donné 2 approches :
Deux disques durs en Btrfs RAID1 et reflinker (i.e. copier avec CoW) la donnée sur le même FS
Un seul disque et copier (copie non CoW) la donnée sur le même FS
Certaines personnes considèrent que la 2e approche est plus « sûre » même si on a qu'un seul disque. De mon côté j'ai adopté la 1ère approche car elle permet de lutter contre le bit rot mais elle a comme inconvénient que je fais trop confiance au CoW. MAIS je ne suis absolument pas sûr de mon coup et je suis ouvert à la discussion sur les avantages/inconvénients des deux approches.
Je vais te dire ce que je pense être la cause de réactions un peu dures plus haut. [...]
Ok j'accepte gracieusement la critique. La prochaine fois je ferai moins concis et peut-être avec une description plus techniquement détaillée. Je voulais faire un journal qui ne soit pas trop rébarbatif avec des termes techniques partout (Btrfs, RAID1, reflink, CoW, bit rot, déduplication, synchronisation, etc.)., mais il n'y a pas de place ici pour les malentendus, même involontaire. Leçon retenue !
[^] # Re: Mes deux centimes
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1. Dernière modification le 22 juin 2017 à 01:30.
On touche aux limites de l'analogie car il faut justement se placer dans le cas où tu bosses seul (je ne fais pas de sauvegarde collaborative, quoique ce serait un sujet intéressant). Mais disons que je souhaite avoir mon dépôt aussi sur Github, pour une raison quelconque (utiliser les beaux outils de Github par exemple, bon c'est peut-être foireux).
Entre ton dépôt local que tu mets à jour toutes les 5 minutes et le dépôt Github sur lequel tu pushes tous les jours, lequel est alors la référence de ton point de vue ?
De mon point de vue les deux sont strictement identiques en fin de journée, donc en fin de journée les deux sont la référence.
Disons que si j'avais une fibre de folie, le fonctionnement serait parfaitement symétrique : je sauvegarderai en permanence sur le serveur distant et de temps en temps je téléchargerai une copie du serveur distant en local (au cas où le serveur tomberait en panne).
Mais sans cette fibre de folie, ce n'est pas « relativement facile d'en couvrir plus avec le stockage distant », c'est juste presque impossible car mon « modèle de menace extrêmement ténu » (erreur de l'utilisateur) est celui qui m'arrive le plus et celui contre quoi je souhaite vraiment me protéger efficacement (et sauvegarder sur un serveur distant, c'est tout sauf efficace).
Oui c'est presque exactement ça. À la différence que je restaure aussi à partir de mon « cache de sauvegarde » (qui est de fait toujours beaucoup plus à jour que la « sauvegarde distante »).
Pas de soucis, si tu le permets voici la citation exacte :
Je n'ai pas changé grand chose dans la structure, mais est-ce que c'est plus clair comme cela :
Donc je doute de mon système car en pratique il n'y a qu'une copie ce qui fait que je fais confiance à fond au CoW pour ne pas la détruire.
On me dit qu'il ne faut pas faire confiance au CoW et qu'il faut une copie physique pour « sécuriser » car la copie du RAID1 ne compte apparemment pas.
Sinon reformulé différemment :
Je n'ai pas confiance dans mon système car je fais trop confiance au CoW car je n'ai qu'une copie de la donnée (en effet même si mon disque est en RAID1, l'autre copie du RAID1 n'est en pratique là que pour corriger le bit rot).
On me déconseille cependant de faire confiance au CoW et on me conseille de faire une autre copie non-CoW de la donnée pour la « sécuriser » (l'autre copie du RAID1 n'est apparemment pas valable pour « sécuriser » la donnée).
Ou bien encore, formulé dans un style plus brut de fonderie et moins littéraire. Étant donné 2 approches :
Certaines personnes considèrent que la 2e approche est plus « sûre » même si on a qu'un seul disque. De mon côté j'ai adopté la 1ère approche car elle permet de lutter contre le bit rot mais elle a comme inconvénient que je fais trop confiance au CoW. MAIS je ne suis absolument pas sûr de mon coup et je suis ouvert à la discussion sur les avantages/inconvénients des deux approches.
Ok j'accepte gracieusement la critique. La prochaine fois je ferai moins concis et peut-être avec une description plus techniquement détaillée. Je voulais faire un journal qui ne soit pas trop rébarbatif avec des termes techniques partout (Btrfs, RAID1, reflink, CoW, bit rot, déduplication, synchronisation, etc.)., mais il n'y a pas de place ici pour les malentendus, même involontaire. Leçon retenue !
Merci