Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ?
L'hypothèse
La gestion de versions permet essentiellement de garder un historique des modifications sur les fichiers et de garder une cohérence entre les fichiers (je laisse volontairement de côté pour l'instant la gestion des branches de développement et le travail collaboratif).
La sauvegarde de données permet essentiellement de garder un historique des fichiers.
Donc à priori la gestion de versions peut servir comme sauvegarde de données (d'ailleurs des logiciels de sauvegarde comme bup s'appuient sur git pour fonctionner). Mais dès que l'on creuse un peu, on se rend compte que cet amalgame provoque des réactions épidermiques chez certains administrateurs systèmes ou spécialiste de la sauvegarde de données.
Le problème
En effet j'ai eu une discussion plutôt animée à ce sujet [1] car je sauvegardais mes données sur ma propre machine (sauvegarde locale, sur le même disque dur donc) avant d'envoyer la sauvegarde ailleurs (sauvegarde distante, sur un serveur distant) pour des raisons de performances et de souplesse [2].
En pratique je procède comme de la gestion de versions distribuée avec un dépôt local et un dépôt distant.
Le point qui fait hurler c'est le fait de sauvegarder sur sa propre machine, ce qui est parfois considéré comme une hérésie. On me dit alors que ce n'est pas une « sauvegarde », et que c'est au mieux un miroir temporaire, un cache, un instantané (snapshot), une bidouille bancale, etc. Bref tout sauf une sauvegarde. Donc la seule vraie sauvegarde c'est celle qui est présente sur le serveur distant.
L'argumentation
Pourtant pour moi j'utilise la sauvegarde locale comme une vraie sauvegarde : je stocke mes fichiers, je restaure mes fichiers, je vérifie mes fichiers, etc. Et la sauvegarde distante n'est là qu'en cas d'extrêmes accidents (cambriolage, feu, foudre, etc.) et je ne l'ai jamais encore vraiment utilisé (sauf pour tester de temps en temps que cela marche bien).
Ne pas considérer ma sauvegarde locale comme une « vraie » sauvegarde c'est comme dire qu'un dépôt local n'est pas un vrai dépôt, et que seul le dépôt distant est valide, ce qui me semble à moi un hérésie.
Alors il est vrai que pour certains une sauvegarde, c'est une sauvegarde qui est « sécurisée » (i.e dans un endroit sûr [3]) et sauvegarder sur sa propre machine n'est pas considérée comme étant « sécurisé ». Pourtant je trouve que la distinction est vraiment artificielle car si on considère qu'un NAS externe est une « vraie » sauvegarde, cette solution partage beaucoup d'accidents potentiels avec ma « mauvaise » sauvegarde locale (cambriolage, feu, foudre, etc.).
Là où je doute un peu de mon système, c'est que comme j'utilise des snapshots pour faire mes sauvegardes locales, 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).
LA question
Donc sans tomber dans la paranoïa (la valeur de mes données est surtout sentimentale), que pensez-vous de cette approche (snapshot) pour sauvegarder ? Pour moi j'avais fondé mon approche sur de la gestion de version distribuée mais j'ai peut-être tout faux…
[1] avec un « responsable de l'architecture informatique d'un grand groupe multinational avec un chiffre d'affaire de plusieurs milliards », ses propres mots, oui je sais c'est un argument d'autorité.
[2] Btrfs snapshot et send/receive
[3] https://stackoverflow.com/questions/549600/is-there-a-fundamental-difference-between-backups-and-version-control/549621#549621
# Titre
Posté par claudex . Évalué à 5.
Pour moi, une sauvegarde en local est une sauvegarde. En plus, comme tu le dis, ça permet de gérer la plupart des cas plus efficacement qu'une sauvegarde distante. Après, il faut voir comment on définit sauvegarde.
Mais pour moi, un bon backup, c'est un backup sur lequel root ne peut pas supprimer ni altérer des données backupés. Sinon, le backup n'est pas à l'abris du premier ransomware venu. Donc, sur une machine distante avec la machine distante qui vient chercher les données (idéalement, il ne faut pas qu'elle puisse écrire non plus sur les systèmes qu'elle backup).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre
Posté par SaintGermain . Évalué à 1.
Merci pour ton avis.
À mon avis, parler de « bonne » ou « mauvaise » sauvegarde créé une fausse dichotomie car la notion de « bon » ou « mauvais » est très subjectif et dépend beaucoup de l'évaluation des risques.
Il y a beaucoup de manières différentes de faire une sauvegarde et c'est toujours un compromis entre l'effort investi et le résultat obtenu.
Dans mon cas d'utilisation, je considère ma méthode comme une approche de gestion de version distribuée. Je suis conscient des risques d'avoir un dépôt local, donc je synchronise de temps en temps vers un dépôt distant.
En pratique au niveau de la gestion de version, je n'ai jamais corrompu/perdu de dépôt local. Idem pour ma sauvegarde locale.
Peut-être que je suis uniquement chanceux ? C'est pour cela que je demande votre avis.
[^] # Re: Titre
Posté par claudex . Évalué à 4.
Pour moi, une bonne sauvegarde, c'est justement une sauvegarde qui permet de se protéger de (presque) tous les problèmes. Ça ne veut pas dire que les autres n'ont pas leur utilité, notamment pour des raisons de performance, ou de coût de granularité (genre, tu fais un snapshot toutes les heures en local mais tu ne le récupère à distance qu'une fois par jour).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre
Posté par totof2000 . Évalué à 3.
Pour moi une bonne sauvegarde est une sauvegarde permettant de récupérer les données que tu ne peux pas perdre sans prendre trop de temps à les restaurer.
En général, on veut tout garder, mais en pratique on peut parfois accepter que des données ne soient pas intégrées à la sauvegarde (dans ce cas il faut pouvoir les rejouer, ou accepter de les perdre définitivement).
Dans le cas d'un dépot git, si tu te contentes de modifications fréquentes avec push fréquent, tu peux te permettre de perdre ton dépot local car il est souvent facile dans ce cas de refaire les modifications que l'on a apportées. S'il n'y a qu'un push tous les 3 mois avec grosses modifications tous les jours, c'est pas la même chose.
[^] # Re: Titre
Posté par claudex . Évalué à 3.
Oui, j'ai simplifié avec les donnés "cache" ou facilement reconstructible. Mais dans l'exemple que tu donne, c'est plutôt le dépôt distant la sauvegarde.
Après, une sauvegarde, c'es très rarement en continue. Donc, il y a toujours un delta de perte de données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre
Posté par dyno partouzeur du centre . Évalué à 8.
Absolument. Même un ficher .bak est une sauvegarde.
Aprrès, il y a plusieurs niveaux de sauvegarde selon le degré de risque encouru et la résilience désirée:
- un backup local sur le même disque te protège contre un rm * malheureux (voir https://linuxfr.org/forums/linux-general/posts/comment-eviter-d-effacer-des-fichiers-avec-rm)
- un backup sur un autre disque contre le disque du pc te protège du disque qui décide de faire zboing d'un coup sans prévenir
- un backup sur un disque réseau te protègera contre la surtension qui crâme tout ton pc
- un backup offline (disque amovible, cd rom, tape), te protègera contre un ransomware qui encrypte tout le réseau
- un backup distant te protègera contre le vol ou la destruction du site (incendie, tremblement de terre, explosion nucléaire selon la distance choisie)…
[^] # Re: Titre
Posté par SaintGermain . Évalué à 1.
Oui c'est moi aussi qui aie posté l'entrée dans le forum ! ;-)
J'essaye de comprendre pourquoi ma question/solution provoque de telle réaction (et surtout si mon approche calquée sur de la gestion de version distribuée) tient la route.
[^] # Re: Titre
Posté par Kerro . Évalué à 6. Dernière modification le 18 juin 2017 à 03:59.
Avis perso : dans les domaines techniques, les réactions brutales
non argumentéessont issues de personnes incompétentes.--> c'est un excellent moyen de savoir à qui ne pas demander conseil, de l'aide, etc
# On en est encore là ?
Posté par oinkoink_daotter . Évalué à 3.
Il me semblait que ce débat était tranché depuis la fin des années 80, mais on dirait que non.
La politique de backup dépend toujours de la criticité des données à sauvegarder et des risques qui pèsent dessus. Sauf à considérer que tes données n'ont aucune importance ou qu'elles ne seront jamais les victimes d'une tragique erreur humaine, d'un accident climatique malheureux ou d'une alim de PC perverse qui embarque des devices dans sa mort, il faut une sauvegarde distante, ou, à tout le (très très) moins une sauvegarde de temps en temps sur disque amovible, gardée hors ligne.
Normalement, dans la plupart des cas, l'analyse de risque dit ça.
Perso, mon NAS est backuppé (chiffré) toutes les nuits chez Hubic, car je suis attaché à mes photos.
[^] # Re: On en est encore là ?
Posté par claudex . Évalué à 4.
C'est ce qu'il fait.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: On en est encore là ?
Posté par oinkoink_daotter . Évalué à 0.
Pas compris ça comme ça.
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
Il te faut quoi de plus pour comprendre ?
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
C'est exactement le genre de réaction épidermique, ou du moins très tranchée que j'obtiens quand je parle de ce sujet. C'est parfois difficile d'avoir une argumentation posée dans ce cas là, ce qui est dommage.
Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
Tout comme la gestion de version distribuée a apporté la notion de dépôt local, il me semble tout à fait concevable d'avoir la notion de sauvegarde locale. Les avantages, défauts et risques me semblent exactement les mêmes.
Est-ce que aujourd'hui il y a encore quelqu'un qui conteste qu'un dépôt local est bien un dépôt ?
Pourtant on trouve des gens pour dire qu'une sauvegarde locale n'est pas vraiment une sauvegarde.
Note que je synchronise bien ma sauvegarde locale vers ma sauvegarde distante (tout comme on doit synchroniser son dépôt local vers son dépôt distant de temps en temps).
Mon évaluation des risques me laisse à penser que faire une synchronisation vers ma sauvegarde distante tous les jours est un peu « overkill ». Et mes données n'ont pas « aucune » importance car j'y tiens, mais j'accepte par exemple de perdre les photos du dernier WE entre potes (et encore il y a toujours des moyens de récupérer) dans le cas improbable (cf. statistiques de ma région) où je me fais cambrioler.
Bien entendu si j'ai des photos d'un mariage ou d'une naissance, il suffit de déclencher la synchronisation juste après l’événement et c'est réglé.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 1.
| Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
C’est tout sauf dépasser.
Le problème de la « sauvegarde » locale, c’est qu’elle ne protège que de peu de choses. En fait de rien du tout généralement.
Si tes données sont au même endroit que tes « sauvegardes » (en tout cas sur le même disque physique), alors il y a un risque plus que non négligeable qu’en cas de corruption des données, ta « sauvegarde » le soit aussi. Sauf cas très particulier (backup sur un disque séparé, non monté ou en read-only seulement) ou erreur très ponctuelle et légère (un fichier supprimé par mégarde, un truc modifié qui n’aurait pas du l’être), en bref ce pour quoi existe la gestion de configuration (qui n’est donc pas une sauvegarde).
Un rm foireux, un disque qui claque sans crier gare, une mauvaise manip pour flasher une clef USB (que celui qui n’a jamais confondu deux /dev/sdx lors d’un dd lève la main) ou un cryptolocker qui passe, et c’est le drame à la fois pour les données et la « sauvegarde » locale. Ce n’est donc pas (en tout cas pour ma part) une sauvegarde viable, tout au plus un cache temporaire.
Une sauvegarde, c’est pour moi une copie des données dont la probabilité d’être impactée en cas de soucis sur les données d’origine est plus que très faible voire si possible nulle.
C’est donc a minima une copie sur un disque physiquement différent de celui des données. Non monté ou en read-only sauf période de backup s’il reste online.
Et même plutôt physiquement déconnecté de la machine des données sauf durant les phases de sauvegarde (disque USB par exemple).
Personnellement, je vais jusqu’à faire tourner chaque mois un des 2 disques de backups offline dans un coffre à la banque pour mes données très sensibles. En plus du disque de backup online présent dans la machine (démonté après chaque synchronisation et qui me sert d’image de base pour la synchro sur les disques offline).
Ça donne donc :
- backup quotidien sur disque online (purgé selon le motif 7 quotidiens, 4 hebdos, 12 mensuels, 10 annuels)
- backup hebdo du disque online sur le disque offline présent chez moi
- échange mensuel du disque offline chez moi avec celui offloadé
Je peux te dire que chaque morceau de ce pattern m’a sauvé les miches, et plus d’une fois.
- backup online : grosse merde sur le disque principal (rm -rf, dd foireux…)
- backup offline : HDD HS data + online (oui je suis un chat noir, mais c’est un scénario classique comme pour le cas du RAID, la resynchro risque de finir d’achever ton disque de backup qui était usé mais pas HS)
- backup offloadé : protection contre perqui ou saisie, cambriolage, incendie
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
Pardon je me suis mal exprimé, ce qui je pense est dépassé c'est que seul une sauvegarde distante peut être considérée comme une « bonne » sauvegarde (ou une sauvegarde tout court)
Là c'est un point de vue extrême que je ne partage pas du tout.
Ce serait comme dire qu'un dépôt local ne sert à rien dans le cas de la gestion de version distribuée.
Mon approche va même plus loin, car comme je l'expliquais, les données et les sauvegardes pointent sur le même espace disque (snapshot/CoW) !
Pour la corruption des données, je pense justement que mon approche est peut-être plus saine car je suis en RAID1 avec Btrfs, donc les corruptions de données peuvent être détectées et corrigées.
Ce qui ne serait pas le cas dans le cas d'une approche traditionnelle où j'ai simplement un disque contenant les données et un disque externe pour contenir la sauvegarde des données (parce que dans ce cas là les corruptions de données sont silencieuses).
Mais effectivement je conçois que le risque est plus grand de perdre les données ET la sauvegarde en même temps lorsque c'est sur la même machine (si la carte mère est défaillante par exemple). C'est ensuite à moi de mesurer le risque par rapport aux bénéfices.
Bien ! tu as le même point de vue que la personne avec qui j'avais discuté (i.e. la sauvegarde locale n'est pas une sauvegarde). J'espère que l'on pourra avoir une discussion posée…
C'est ta définition de la sauvegarde. Mais ce n'est certainement pas celle qui est officielle (voir wikipedia par exemple). De mémoire il n'est nul part indiqué où doivent se trouver les données sauvegardées (répertoire à part ? partition à part ? disque à part dans l'ordinateur ? disque externe ? disque distant ?).
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 3. Dernière modification le 17 juin 2017 à 20:34.
Tu ne protèges pas du tout de la même chose avec un DSCM et avec une sauvegarde.
Un DSCM ne protège ne protège que d’une corruption (à prendre au sens générale, ça peut être le matos, le système de fichiers, un dev qui a fuck…) interne du dépôt (un dev a fait un rm -rf des fichiers du dépôt). Ça ne protège pas des corruptions externes (un dev a fait un rm -rf du .git, un secteur défectueux empêche la lecture de méta-données…).
Tu peux par exemple te retrouver avec un dépôt git fucké avec plus aucune commande qui ne fonctionne à cause d’une corruption des données du dépôt.
Un backup va te protéger de ces corruptions externes justement.
Dit autrement, un DSCM permet de remonter à un instant T-X, un backup permet de garantir que si ça marchait à l’instant T, cet instant T refonctionnera à l’instant T+X une fois restauré (alors qu’un dépôt qui fonctionne à l’instant T peut être impossible à remettre dans l’état de l’instant T s’il est corrompu).
Ce qui est pire que tout.
Tu as le moindre problème externe, tu as tout perdu.
Un backup ne suppose rien de l’état de ton système justement.
Je ne connais que trop de gens qui se croyaient à l’abris avec du RAID1. Faire du RAID, c’est très compliqué à faire proprement.
Par exemple si tu mets 2 disques issus du même fabriquant avec des numéros de série relativement proche, il y a de très grandes chances que lors qu’un des disques sautera, la reconstruction achèvera le 2nd disque, qui aura grosso modo la même durée de vie.
Faire du RAID1 proprement, c’est acheter 2 disques de constructeurs différents, à 2 dates relativement éloignées (plusieurs mois, les composants physiques étant presque tous fabriqués au même endroit, quelque soit le fabriquant).
Sans parler que btrfs et RAID ne te protègeront pas d’un « rm -rf / » ou d’un dd foireux.
Le RAID, c’est comme les DCSM, ça n’est pas une solution de backup.
Les corruptions de données ne sont pas silencieuses avec des backups.
Des backups, ça se teste régulièrement. L’état SMART des disques est à vérifier régulièrement. fsck à passer régulièrement.
Le fait de les avoir unmount/offline/offload protège aussi le matériel. Étant moins sollicités, la durée de vie des supports physiques est plus longue. Un disque qui passe 1 mois dans un coffre à la banque ne s’use pas, pas plus que celui posé sur mon étagère.
Et encore une fois, btrfs/raid ne te protège pas des « corruptions » logicielles (rm -rf, dd…)
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 0.
J’ajouterai même mieux :
Un DSCM permet de remonter à tout instant T sous réserve que le dépôt soit encore opérationnel à l’instant T+X
Un backup assure que s’il était opérationnel à l’instant T, il est restaurable et fonctionnel à l’instant T+X
Un DSCM est un « rewind-backup », alors qu’un backup est un « forward-backup ».
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
Ce n'était pas l'objet de ma remarque (homme de paille ou mauvaise compréhension ?).
Je disais que dire qu'une sauvegarde « locale » est complètement inutile par rapport à une sauvegarde « distante » c'est comme dire qu'un dépôt « local » est complètement inutile par rapport à un dépôt « distant ». C'est ton avis extrême que je critiquais.
L'objet de la remarque n'est pas du tout de comparer l'avantage d'utiliser git comme outil de sauvegarde (ce qui est un tout autre sujet).
Pour moi la sauvegarde « locale » ne permet absolument pas de se passer de la sauvegarde « distante », mais elle me rend bien service et me sert régulièrement pour récupérer mes sauvegardes en cas d'accidents.
De même mes dépôts locaux me sont bien utiles mais ne permettent pas de se passer d'un dépôt « distant ».
Donc dire que cette sauvegarde « locale » ne protège de rien n'est absolument pas vrai dans mon cas.
Encore une déclaration extrême… On va vite arrêter la discussion si cela continue comme cela.
Ce qui est pire que tout c'est de ne pas avoir de sauvegarde du tout, le fait de copier localement (même maladroitement) les données c'est déjà mieux que rien.
Et oui je suis conscient que si j'ai un problème externe je perds tout. Tout comme un développeur qui travaille sur son dépôt local perd tout s'il n'a pas synchronisé sur le serveur distant.
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ? La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Il n'est pas là du tout pour servir de sauvegarde.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog. Les fichiers deviennent corrompus et peuvent écraser la bonne version qui était dans les sauvegardes lors de la prochaine sauvegarde complète (cela m'est arrivé, c'était un mauvais câble du disque dur qui était en cause).
Encore une fois btrfs/raid est là uniquement pour la corruption des données et le bit rot. Je n'ai jamais dit qu'il était là pour protéger mon rm -rf.
J'ai un peu l'impression que tu te braques sur certains mots-clés après avoir lu en diagonal sans chercher à comprendre ce que je cherchais à exprimer ?
Quelqu'un d'autre peut confirmer si je me suis bien exprimé ou bien c'est à moi de m'exprimer plus clairement ?
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 0.
Avoir une copie locale a effectivement de l’intérêt (c’est même pour ça qu’a été inventé DSCM). Mais ce n’est pas une sauvegarde (en tout cas pas du point de vue « admin sys »). Faudrait trouver un autre terme.
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Ça n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
La réponse est non et sera invariable.
Une sauvegarde doit permettre de revenir à un état cohérent et utilisable passé, en faisant un minimum d’hypothèses sur la procédure à suivre et sur l’état courant du système (en particulier, on doit supposer le système d’origine inutilisable au moment de la restauration).
En particulier, un backup est un système qui devrait te permettre une restauration de service même si l’ensemble de ton système d’origine a disparu de la surface de la planète.
Ou dit encore autrement, la seule hypothèse de restauration doit être la possession d’un backup (sachant que ton système lui, doit être considéré 100% KO).
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
[^] # Re: On en est encore là ?
Posté par jfmartin . Évalué à 2.
C'est toi qui fait erreur dans ce cas. Il a précisé qu'il utilise Btrfs pour son RAID 1.
ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à -1.
| ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
Je veux bien un papier sur le sujet, parce que je ne vois pas comment c’est possible, en tout cas sur RAID1.
Si ZFS|Btrfs se rend compte d’une incohérence de données entre le checksum et les données remontées par le disque, ils n’ont aucun moyen de corriger l’erreur puisqu’ils ne peuvent pas savoir quelle erreur a réellement été commise entre
Après tu peux faire des heuristiques à la con pour chercher à corriger (si D1≠D2 on vérifie si D1 ou D2 match C1=C2, ou encore si C1≠C2, on garde le C qui matche D1=D2), mais il reste plein de trous dans la raquête (D1≠D2 et aucun C qui match, C1≠C2 et pas de D qui match, C1≠C2 & D1≠D2, etc) et tu peux empirer encore plus la situation en choisissant une mauvaise heuristique.
C’est tout le problème du RAID1 : dès qu’un truc pète (hors erreurs matos), il est préférable de dégager un disque au pif que de chercher à corriger les erreurs.
Et c’est aussi pour ça que RAID1, c’est pour moi uniquement une question de résilience et certainement pas de robustesse. Ça permet de conserver une infra physique fonctionnelle en cas de corruption, à quelques glitches près sur les zones éventuellement erronées qu’on restorera depuis les backups si nécessaires une fois le matos changé.
Si tu veux de la résilience (pas de down) et de la robustesse (pas de perte), tu passes sur du RAID5.
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
C'est un sujet bien connu. Tu trouves pleins de trucs sur le sujet en cherchant un peu (j'ai même donné un lien dans ma réponse plus bas).
Tu peux aussi chercher "btrfs raid1 corrupted data" ou "btrfs raid1 bit rot" ou la même chose avec ZFS.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 0.
Oui, et aucun article n’explique comment fait btrfs pour corriger une erreur de bit rot, sachant qu’il n’y a pas de sur-redondance de données (seulement 2 strips) et uniquement 1 bloc de parité (donc indécidable si c’est le bloc de parité qui s’est pris le bitrot ou un strip de data).
Tout le monde est d’accord pour dire que ça détecte le bitrot (comme tout système raid). Nul part je ne vois que ça le corrige (sauf raid5 minimum où un consensensus est possible), sinon via un retour arrière via l’historique COW (qui risque alors soit de corrompre le fichier si le rollback est au niveau bloc, soit avec pertes de données s’il est au niveau fichier).
[^] # Re: On en est encore là ?
Posté par jfmartin . Évalué à 2.
Checksum = metadata => Tu l ecris autre part.
Si tu as un block qui part en *****, les metadata sont pas corrumpue.
Btrfs écrit plusieurs fois les metadata, y compris si tu utilises un seul disque.
[^] # Re: On en est encore là ?
Posté par totof2000 . Évalué à 2.
Hum … "autre part" c'est sur un des disques potentiellement défectueux ? Moi dans tout ça j'en déduis qu'un RAID 1 à 2 disques ne suffit pas (un peu come un clusrter à 2 masters qui risque de partir en split brain). Il faut un 3eme pour être quasi sûr de ne pas avoir de donnée corrompue.
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 0.
Je ne sais pas si tu fais exprès ? Il suffit de remonter quelques lignes plus haut et de voir ce que j'ai écris :
Cela ne signifie pas du tout que j'utilise mon RAID1 comme backup ! Cela signifie juste que cela me protège contre les données corrompues (bit rot par exemple).
Un RAID1 cela ne protège certainement pas contre les "rm -rf" ou "dd /dev/sd0" (i.e. les erreurs utilisateurs).
Là tu perds un peu en crédibilité. Un petit article pour t'aider à comprendre :
https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/
Tu n'as pas cherché à comprendre mon explication qui démontre qu'un fichier corrompu (sur ton disque dur d'origine) n'est pas forcément détecté par ton système et peut par la suite remplacer tes sauvegardes.
Désolé mais tu mélanges tout (copie online/DSCM/cow/btrfs/raid/whatever).
Je tente une dernière fois :
1. gestion de versions et sauvegarde de données me semble très similaire
2. je me suis inspiré de la gestion de version décentralisée, pour élaborer ma stratégie de sauvegarde : local et distant
3. Btrfs est anecdotiquement utilisé pour faire la sauvegarde locale (snapshot) mais j'aurais pu utiliser un bête "cp" et le résultat aurait été le même
4. Btrfs/RAID1 est anecdotiquement utilisé pour détecter/corriger les données corrompues (bit rot), c'est juste un bonus qui ne change pas grand chose à ma stratégie
C'est ta propre définition de la notion de sauvegarde, Wikipedia (en particulier la définition anglaise) donne une autre vision (que je partage, mais c'est mon avis).
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 18 juin 2017 à 02:06.
Ça ne protège pas plus d’un bitrot justement.
Le controlleur RAID détectera une incohérence, ne sera pas capable de déterminer qui des 2 strips a raison et éjectera un des 2 côtés sans aucune semonce.
C’est RAID5 minimum qui permet de corriger le bitrot en regardant le consensus des grappes. RAID1 ne permet que de le détecter et ne permet aucune action corrective (sinon à la hache en dégageant une grappe).
Et ça ne fait pas ce que tu dis.
C’est effectivement COW, ce qui veut dire qu’en cas de corruption, les données PRÉCÉDENTES vont être dispos.
Si ton fichier est dans sa 1ère version et que tu te prends un bitrot, t’es cramé, il n’y a pas plus d’historique.
Et même dans le cas où tu as des données plus ancienne, tu ne sais pas revenir à l’état intègre de la version « bitrotée ». Ça continuera à te donner un fichier final corrompu d’ailleurs si le FS ne rollback qu’un bloc et non tous les blocs de ton fichier (et dans ce cas tu perds encore plus de données).
Faut pas croire que c’est magique les FS hein. Même ceux « next-gen ».
Je ne vois pas ce que ça vient faire là.
Et tu as le même problème sur ton truc local hein.
Un fichier corrompu non détecté merdera ad vitam éternam partout. En local, online, offline, offloadé. C’est pour ça qu’il est important de tester régulièrement ses backups.
Similaires techniquement peut-être, mais dans leurs usages pas du tout.
Comme déjà dis, un backup ne suppose pas que ton système soit opérationnel pour pouvoir faire une restauration. Ta copie locale si.
« Backups have two distinct purposes. The primary purpose is to recover data after its loss, be it by data deletion or corruption. »
La page anglaise dit la même chose que moi : un backup suppose la perte complète du système principal. its loss, ce n’est pas its corruption. Tes données ne sont plus là, et considérées comme non réparables depuis le système principal.
« The secondary purpose of backups is to recover data from an earlier time »
La possibilité de restauration d’un backup après la perte de données implique un retour en arrière. Ton système local ne couvre que le 2nd usage (« retourner en arrière »), pas le 1er (« récupérer une perte de données »).
https://www.appvizer.fr/magazine/services-informatiques/sauvegarde/sauvegarde-archivage-stockage-quelles-differences-1443109474
http://blog.watsoft.net/actualite-watsoft/difference-entre-larchivage-et-la-sauvegarde-dun-serveur-de-messagerie/
http://www.gestion-documents.fr/archivage-vs-sauvegarde/
https://blog.netexplorer.fr/stocker-archiver-sauvegarder-differences/
J’aurais tendance à dire que ta solution locale est de l’archivage, et non de la sauvegarde.
D’ailleurs, je trouve le dernier article assez clair au niveau des définitions :
« Je veux pouvoir récupérer mes données en cas d’évènements majeurs altérant leur accessibilité » ⇒ sauvegarde (côté « everything is doomed »)
« Je veux m’assurer de pouvoir récupérer mes données sur le long terme à tout instant » ⇒ archivage (côté « something fucked »)
« Je veux pouvoir accéder à mes fichiers où que je sois, et les partager avec mes collègues » ⇒ stockage (côté « the world is cool »)
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
Quelqu'un peut-il trouver un moyen de lui faire comprendre ? Moi je n'y arrive pas.
Au secours…
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 18 juin 2017 à 02:41.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
[^] # Re: On en est encore là ?
Posté par totof2000 . Évalué à 2.
Là c'est toi qui a un problème. Si tu veux qu'on te dise que ta façon de faire est la bonne, je crois que tu peux aller voir ailleurs§. Maintenant si ta façon de faire te suffit, tant mieux pour toi, mais le jour ou tu perdras tes données tu ne pourras pas dire "ben sur LinuxFR ils m'ont dit que ce que je faisais suffisait".
[^] # Re: On en est encore là ?
Posté par totof2000 . Évalué à 1.
Euh … en te lisant, j'ai compris que ton RAID servait de sécuriser tes sauvegardes. Donc pas d'homme de paille : là c'est toi qui a un problème.
Qu'est-ce que tu ne comprend pas dans "Des backups, ça se teste régulièrement" ? Tester des backups, c'est pas seulement tester qu'on est capable de redescendre ses fichiers, mais c'est tester aussi que les données sont utilisables.
Moi j'avia jusqu'à maintenant l'impression que tu ne t'exprimais pas clairement parce que tu as les idées un peu confuses, là j'ai l'impression que tu es un peu de mauvaise foi et que tu refuses de te remettre en question.
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1.
Écoute c'est très simple, j'ai fait un grep sur RAID sur les messages plus haut et j'ai trouvé :
Donc bon je ne vois pas très bien comment je peux être plus clair pour dire que le RAID est uniquement là pour la corruption de données.
Oui effectivement j'ai peut-être sous-estimé comment certains peuvent se braquer dès qu'ils voient 'sauvegarde' et 'RAID' dans le même texte sans chercher à vraiment comprendre. J'aurais peut-être dû mettre en gros que mon RAID1 n'a rien à voir avec la sauvegarde ou même éviter de parler de RAID.
Tu n'as rien compris, cela n'a rien à voir avec tester que les données sont utilisables, mais alors rien à voir.
Je tente une dernière fois :
1. Tu as un fichier original A
1. Tu fais une sauvegarde B (sur un disque sur Mars, je m'en fous)
1. Le fichier original A devient corrompu (silencieusement) et devient A1
1. Ta sauvegarde B est toujours intacte, tu peux la tester autant de fois que tu veux si cela te fait plaisir
1. Comme le fichier A1 n'est pas détecté comme étant changé par rapport à A, la sauvegarde B n'est jamais mis à jour lors des backups différentiels
1. Un de ces jours, tu vas faire une nouvelle sauvegarde complète cette fois, et A1 sera sauvegardé comme C
1. Un de ces jours, tu vas effacer l'ancienne sauvegarde B et tu n'auras plus que A1 et C, donc des fichiers corrompus.
La seule façon d'éviter ce cas de figure c'est : faire une restauration de la sauvegarde complète de temps en temps et faire un réel diff complet avec les données d'origine et inspecter chaque changement : je ne sais pas s'il y a grand monde qui fait cela.
Là où les experts ne sont pas d'accord entre eux, c'est comment réagit le FS quand un fichier est corrompu (via bit rot, rayons cosmiques, câble défectueux, disque HS, etc.). En particulier est-ce que le FS est mis au courant ou pas (date de modification du fichier par exemple).
[^] # Re: On en est encore là ?
Posté par totof2000 . Évalué à 3.
Le RAID n'est ABSOLUMENT PAS un outil de "sauvegarde" mais de disponibilité. PArler de RAID dans un sujet traitant de la sauvegarde est complêtement HS. Idem pour le BTRFS : rien a voir avec la sauvegarde.
Tout est dans ta dernière phrase. Si ça te suffit, ce n'est pas un problème: faut juste que tu connaisses bien les risques et que tu les acceptes.
Pour ma part je suis d'avis que la sauvegarde locale peut être suffisante si on accepte de perdre ses données si le disque ou la machine flanche, ou si on se fait voler sa machine …. Elle ne l'est pas (et dans ce cas ce n'est pas une sauvegarde en tant que telle) si on n'accepte pas ces risques.
C'est impossible à déterminer parce que les mesures que tu va prendre pour ta sauvegarde dépendront de plein de choses :
De ces quatres éléments découlera la solution utilisée. Et bien souvent une solution de sauvegarde est un compromis entre ces trois critères.
[^] # Re: On en est encore là ?
Posté par oinkoink_daotter . Évalué à 1.
Ben dans la mesure où tu as supprimé de ta citation tout ce qui n'allait pas dans ton sens (ce qui est après "importance") et qui montre des risques que tu ne couvres pas, je ne peux pas grand chose pour toi.
Cela dit, le post de gle< plus haut est un bon détail. Après, c'est ton modèle de menace et surtout tes données. Your data, your rules.
[^] # Re: On en est encore là ?
Posté par SaintGermain . Évalué à 1. Dernière modification le 18 juin 2017 à 17:16.
La citation était là pour mettre en évidence que ton avis était extrême et très tranché. Que cela plaise ou non le monde n'est pas complètement blanc ou noir.
C'est souvent impossible d'argumenter avec des gens qui prennent de telles positions dès le début d'une discussion.
Les risques que je ne couvre pas, j'en suis bien conscient merci. J'ai maint et maint fois répété qu'une sauvegarde locale ne peut se concevoir qu'avec une sauvegarde distante. Donc tous les risques cités sont déjà couvert par la sauvegarde distante.
La sauvegarde locale est là pour des raisons de souplesse et de performance.
Donc oui la sauvegarde locale peut tuer les bébés phoques et partir en combustion spontanée à tout moment. Content ?
[^] # Re: On en est encore là ?
Posté par oinkoink_daotter . Évalué à 1.
Ben du coup, si j'ai bien compris, de ça et de ton post plus haut, en fait, tu as aussi une sauvegarde distante, même si moins régulière ?
Je n'avais pas compris, ça. Du coup, il n'y a plus de sujet.
# Rhétorique
Posté par barmic . Évalué à 7.
Tu fais de la rhétorique (d'autres ici aussi). Backup, sauvegarde, bon/mauvais,…
Je me fous de savoir le nom qu'il faut donner aux choses, ça n'est pas très intéressant. Ce qu'il faut savoir c'est quelle sécurité, tu as pour tes données. Pour cela il faut que tu évalue d'une part les risques et d'autre part l'importance de tes données.
Ta copie locale te donne une sécurité très faible. Elle protège des erreurs de manipulation, mais d'aucun problème technique (fs corrompu, disque qui meurt,…), d'aucun problème extérieur (vol du matériel) ni d'aucune attaque (ransomeware).
Si tu es le seul à pouvoir évaluer l'importance de tes données, ce que je vois généralement c'est une grosse différence de comportement entre ceux qui ont confiance en leur disque (souvent ils n'ont jamais eu de problème avec) et ceux qui ne leur font pas confiance (généralement ils t'expliquent comment ils ont déjà perdu des données).
Bref l'importance c'est de comprendre ce que protège ta méthode et d'évaluer la réalité des risques (est-ce que tu risque le vol ? est-ce que ton disque va mourir ?…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rhétorique
Posté par SaintGermain . Évalué à 2.
Des noms, des noms ! ;-)
Tu veux plutôt dire « Ce qu'il faut savoir c'est quel niveau de sécurité tu veux pour tes données » ?
Dans ce cas, oui c'est une évidence mais je suis d'accord avec ton affirmation.
Oui tout à fait (encore que bon avec Btrfs/RAID1 je suis protégé en théorie contre le disque qui meurt ou les données qui deviennent corrompues).
Mais il faut bien comprendre que la sauvegarde locale ne peut être envisagée qu'à condition que l'on dispose d'une sauvegarde distante.
Ce sont à peu de choses près les mêmes problématiques qu'un dépôt local vs dépôt distant dans le cas de la gestion de versions : on peut avoir seulement un dépôt distant (CVS) ou un dépôt local et un dépôt distant (Git), mais pas juste son propre dépôt local (enfin si juste pour jouer ou expérimenter).
Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
Au risque de me répéter, mon approche combine une sauvegarde locale et une sauvegarde distante. Donc pour le vol et le disque qui meurt, c'est couvert.
La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi. Tout comme le fait de travailler avec un dépôt local au lieu de juste un dépôt distant. Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Si les données étaient critiques, je synchroniserais tous les soir. Comme elles ne changent pas tant que ça et qu'elles ne sont pas si importante que cela, je synchronise tous les mois environ (ou juste après un changement important).
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . Évalué à 0.
| Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
C’est là que je ne te suis absolument pas…
Tu fous quoi en RAID1 si tu n’as pas confiance en tes disques ? :s
C’est du RAID5 minimum qu’il te faudrait du coup, puisque qu’un disque qui pète sur du RAID1 peut entraîner la perte de la grappe complète si c’est le mauvais disque qui est sorti de la grappe en 1er (déjà vécu plusieurs fois)…
| La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi.
N’appelle pas ça sauvegarde alors.
| Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Et c’est typiquement ces cas-là où une sauvegarde (donc offline ou a minima sur disque physique séparé) est utile.
Tes trucs locaux ont une probabilité plus que non nulle d’être AUSSI impacté en cas d’erreur humaine ou logicielle ou d’une corruption de données/disques.
Elles sont physiquement trop proches des données « live » pour pouvoir dire l’inverse.
[^] # Re: Rhétorique
Posté par SaintGermain . Évalué à 1.
Je ne sais pas combien de fois il faut que je te le dise, mais le RAID1 est là uniquement pour la corruption de données, PAS POUR LA SAUVEGARDE !!!
Si j'ai une donnée corrompue, je peux récupérer la donnée avec l'autre disque du RAID1.
Si j'ai un disque qui pète, je peux bien entendu aussi récupérer grâce à l'autre disque du RAID1, mais SURTOUT grâce à la sauvegarde distante.
Le RAID1 me protège aussi contre le disque qui pète, c'est cool, mais ce n'est pas sa fonction première, c'est juste un effet de bord sympa.
Un snapshot read-only, il faut quand même se lever de bonne heure pour arriver à l'effacer par erreur ou via un logiciel. Même avec un "rm *" en root tu n'y arrives pas. Le seul cas que l'on peut envisager c'est une erreur dans le kernel.
Je ne sais pas ce que tu entends par corruption de données/disques ?
Parce que j'ai plusieurs fois répété que pour les corruptions type « bit rot », j'étais protégé par Btrfs RAID1.
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . Évalué à -2.
Sauf que comme je l’ai dis, on ne sait PAS corriger une erreur avec RAID1. on ne peut que détecter une erreur, on ne sait pas quelle donnée est la bonne. Ça ne protège donc pas d’un bitrot, ça permet uniquement de le détecter et de dégager une des grappes au pif pour pouvoir laisser la prod continuer à tourner en attendant une resynchro.
Il faut du RAID5 pour savoir corriger l’erreur une fois détecter, via la comparaison avec les 2 disques fonctionnels qui disent la même chose alors que le disque défectueux dit une connerie.
Un secteur défectueux. Un dd à la con qui te ruine ta table des partitions.
Et bien reli bien les docs, ce n’est pas le cas. Pas en RAID1.
[^] # Re: Rhétorique
Posté par claudex . Évalué à 4.
Sauf que Btrfs fait un checksum des données. Du coup, tu sais quelle est la bonne, c'est celle dont le checksum est correct.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . Évalué à -1.
Et donc c’est tout sauf gratuit en terme de perfs… Et certainement pas l’outil magique.
Surtout que du bit rot, en pratique, je ne suis pas sûr d’en avoir rencontrer une seule fois dans ma vie…
Les disques du commerce grand public sont garanti à 1014 octets pour 1 erreur de bit, soit 12To avant de voir la moindre erreur. Les disques professionnelles sont à 1015 (120To). Et d’ailleurs ce chiffre concerne les HDD, les SDD ont une durée de vie plus faible.
C’est d’ailleurs confirmé par des études empiriques chez Microsoft : https://www.microsoft.com/en-us/research/publication/empirical-measurements-of-disk-failure-rates-and-error-rates/?from=http://research.microsoft.com/pubs/64599/tr-2005-166.pdf
Et enfin, ils préviennent aussi que quand un truc disjoncte, d’autres trucs disjonctent en même temps pas très loin :
[^] # Re: Rhétorique
Posté par claudex . Évalué à 5.
En fait, tu troll gras. Tu dis que ça ne protège pas. Quand on te montre que si, tu dis que ça ne sert à rien.
Bref, je m'arrête là.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Rhétorique
Posté par totof2000 . Évalué à -1.
Ben on peut te dire la même chose : Je ne sais pas combien de fois il faut que je te le dise, mais le RAID1 NE PEUT PAS TE PERMETTRE DE PR2VEN§IR LA CORRUPTION DE DONNEES.
Vous illustrez à vous deux la raison pour laquelle ce n'est pas possible : vous avez tous les deux un point de vue différent sur ce sujet et vous n'êtes pas d'accord ? Qui a raison ? C'est pareil pour tes 2 disques : ils ont tous les deux un point de vue différent sur ce qu'est la réalité (la valeur d'un bit). Qui a raison ? §Ce qu'on te dit depuis le début c'est qu'avec 2 disques tu ne peux pas savoir (a moins d'avoir une remontée SMART qui t'indique qu'un des disques est défectueux,, auquel cas tu peux supposer que le disque qui remonte des erreurs a tort, mais tu ne peux pas en être certain).
La difficulté est de savoir qui est corrompu.
D'ou est-ce que tu sors ça ?
Un dd sur le mauvais device en root ça compte ?
Et c'est là que tu te trompes. Tant que tu n'auras pas compris ça, la discussion restera au point mort.
[^] # Re: Rhétorique
Posté par totof2000 . Évalué à 0.
Non.
[^] # Re: Rhétorique
Posté par totof2000 . Évalué à -1.
C'est faux.
Un dépot distant n'est là que pour partager, pas pour sauvegarder.
Si tu as un dépot local, et que tu as une sauvegarde distante de ton dépot ( un truc du genre tar.gz de ton fs stocké offline), tu n'as pas besoin de dépot distant.
[^] # Le mot de la fin ? -- Was: Rhétorique
Posté par jfmartin . Évalué à 1. Dernière modification le 18 juin 2017 à 14:45.
Je propose l'utilisation de cette image afin d'éviter d'atteindre le point Godwin.
[^] # Re: Le mot de la fin ? -- Was: Rhétorique
Posté par SaintGermain . Évalué à 1.
Oui tu as sans doute raison.
Je ne vois pas très bien comment convaincre quelqu'un que Btrfs (ZFS) + RAID1 puisse détecter et réparer des données corrompues/bit rot quand cette personne ne veut rien comprendre (ou même chercher un minimum sur Google) : cause perdue, j'abandonne.
# De l'importance des mots
Posté par nico4nicolas . Évalué à 2.
Je sais que ce n'est pas vraiment répondre à la question mais je pense que le premier problème se trouve dans la question… ou dans l'interprétation qu'en font les "experts". Une sauvegarde est le fait d'enregistrer des données sur une mémoire non volatile. J'ouvre mon éditeur de texte favori, je tape mon texte puis je l'enregistre sur le disque de ma machine ou celle d'une machine distante (type cloud), c'est une sauvegarde.
La question qui se pose, c'est sur la copie de la sauvegarde et la sûreté de celle-ci. Je pense que poser la question en termes de sûreté de copie/sauvegarde/enregistrement conduirait plus rapide à considerer la nature et l'importance des données sauvegardées.
Aussi surprenant que cela puisse paraitre, ma liste de courses de la semaine 17 de l'année 2016 a moins d'importance que la configuration du serveur de mon entreprise. Appliquer le même raisonnement pour la sûreté de ces deux copies de sauvegarde me parait être la seule vraie hérésie.
[^] # Re: De l'importance des mots
Posté par steph1978 . Évalué à 2.
Désolé mais enregistré des données se dit en français "enregistrement des données".
Tu confonds avec "save" en anglais.
Sauvegarde se traduit par "backup".
# protection de données
Posté par steph1978 . Évalué à 3. Dernière modification le 19 juin 2017 à 23:32.
Quand on parle de sauvegarde, le vrai besoin qui est adressé est la protection de données.
Cela passe par une analyse de risque : quelle donnée, quel risque, quel probabilité d’occurrence, quel impacte sur des choses importantes (mes souvenirs, l'effort pour les recréer, etc.).
De cette analyse découle les moyens à mettre en œuvre : copie distante, chiffrée, en de multiples endroits, dans de multiples versions, dans différents formats, etc.
La gestion de configuration ("version control") et la sauvegarde ont une intersection sur "multiple versions" qui permet de se protéger de l'erreur humaine. Mais pour que de la gestion de configuration réponde à tous les aspects de la protection de donnée, il faudrait … sauvegarder les données de son système de gestion de configuration.
La gestion de configuration répond en réalité à un autre besoin qui est la traçabilité : quel était l'état de mes source qui a permis de construire telle version de mon logiciel. Qui a introduit le bug numéro n dans les sources. Il répond aussi au besoin de résolution des conflits en cas de modification concurrentes.
Si tu perds ton git, tu perds l'historique. Si une copie locale et un git te suffise, alors tu n'avait pas besoin d'un git mais d'un simple rsync.
[^] # Re: protection de données
Posté par SaintGermain . Évalué à 0.
Oui j'avais bien indiqué que je laissais de côté le travail collaboratif. La gestion de version permet beaucoup plus de choses que de garder un historique d'un fichier.
Je n'ai pas dit que j'utilisais git pour faire mes sauvegardes, j'ai dit qu'à priori la gestion de version peut aussi servir à sauvegarder ses données. C'est le principe de bup d'ailleurs pour ne citer qu'un logiciel parmi d'autres, ce qui valide mon hypothèse (même si bup n'est peut-être pas encore utilisable en production).
Pour ma part je m'inspire de la gestion de version distribuée (dépôt local et dépôt distant) pour faire mes sauvegardes. La sauvegarde peut être faite avec git, cpold ou rsync. L'implémentation exacte n'a que peu d'importance.
Et non si tu relis ma description, une copie locale et un git ne suffit pas : il faut une copie distante. La copie locale, tout comme un dépôt local, n'est pas absolument nécessaire (après tout on s'en sortait à peu près avec CVS avant…). C'est surtout là pour avoir plus de souplesse et de performance.
[^] # Re: protection de données
Posté par steph1978 . Évalué à 2.
Bup reprend une technologie déjà utilisée par un logiciel de gestion de configuration et s'en sert pour faire de la déduplication. Mais c'est bien un logiciel de sauvegarde.
[^] # Re: protection de données
Posté par SaintGermain . Évalué à 1.
Ben c'est exactement ce que j'ai dit :
Bup s'appuie sur Git pour sauvegarder les données.
Par contre on voit la limite du système, car la dernière fois que j'ai regardé, c'était assez rock'n'roll pour effacer les anciennes sauvegardes (Git n'est en effet pas vraiment conçu pour ça, ce serait même le contraire).
[^] # Re: protection de données
Posté par steph1978 . Évalué à 2.
Je vais être relou en insistant mais bup ne reprend pas un principe de gestion de configuration mais une technologie : packfile, qui lui permet de faire de la déduplication plus efficacement qu'un rsync par exemple.
Donc ça ne valide pas le principe IMHA.
[^] # Re: protection de données
Posté par SaintGermain . Évalué à 1. Dernière modification le 21 juin 2017 à 08:48.
Eh bien si on regarde comment bup fonctionne :
https://github.com/bup/bup/blob/master/DESIGN
On trouve ces infos intéressantes :
Donc bon je vais être moi aussi un peu lourd et insister : bup valide bien le principe.
En gros git aurait été plus performant sur le nombre/taille des fichiers et il aurait stocké les metadata, bup n'aurait été qu'une très fine enveloppe autour de git.
Et rien que le fait que l'on parle de « bup repository » devrait être un gros indice, comme quoi le principe est fortement inspiré de la gestion de version.
# Ne pas confondre sauvegarde et gestion de version
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 2.
un gestionnaire de version ou rsnapshot en local sont bien si on fait des bêtises sur ses fichiers, mais c'est pas une sauvegarde.
Une sauvegarde protège contre une défaillance ou destruction de la machine (voir du site).
Normalement la machine ne doit pas avoir accès aux sauvegardes.
Après la sauvegarde sur disque dur externe ou bande j'y crois pas, si il doit y avoir une intervention humaine c'est foireux.
Le mieux c'est automatiser, j'ai une instance nextcloud (pour la famille) l'avantage j'ai les mêmes données entre mon ordinateur fixe et mon laptop.
Après 4 fois par jours j'ai mon serveur à la cave qui se connecter sur ma vm qui contient mon nextcloud (soyoustart) et qui fait un snapshot (rsnapshot).
Bon d'accord j'ai une connexion à 500mbs/50mbs je suis un privilegier.
Par contre la vm qui contient nextcloud ne peut pas se connecter sur mon serveur rsnapshot, donc si ma vm est compromise ou autre j'ai deux ans pour le remarquer mais mon serveur rsnapshot ne sera pas impacté.
Bon si ma maison brûle ou autre il me reste plus qu'a prier que le serveur chez soyoustart ne pête pas en même temps.
Après il faut vérifier les sauvegardes, voir qu'elle tournent et de temps en temps restaurer pour voir que ça joue, vérifier qu'elle tourne je le fait un fois pas mois.
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . Évalué à 1.
N'est-ce pas un peu réducteur ?
De mon côté, que ce soit à la maison ou en entreprise, j'ai bien plus de cas où j'utilise les sauvegardes à cause d'une erreur utilisateur (PBKC).
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 2.
Oui c'est volontairement réducteur ;-)
après c'est clair dans la boite ou je bosse (je suis administrateur système) quand un utilisateur fait une erreure on restaure depuis les sauvegardes
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . Évalué à -1.
Donc le fait qu'une sauvegarde protège contre les erreurs utilisateurs, ce n'était pas le but de le sauvegarde mais c'est juste un effet de bord sympathique ? ;-)
Plus sérieusement, puisque tu es administrateur système, quel est ta proportion entre utiliser la sauvegarde suite à une erreur utilisateur et suite à une défaillance/destruction de la machine ?
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par ckyl . Évalué à 0.
Tu ne ferais pas beaucoup de bruit pour dire un truc aussi simple que:
rsync --link-destde son homedir dans son homedir pour avoir une timemachine.Le reste n'est qu'analyse de risque.
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . Évalué à 1.
J'ai lu récemment quelque part que les sauvegardes c'est comme rouler en voiture : celui qui roule moins vite que toi est un idiot et celui qui roule plus vite que toi est un maniaque (bizarrement cela s'applique aussi à la sécurité informatique).
Plus sérieusement, je pense que ce fil est révélateur du problème de fond : certains pensent qu'une sauvegarde est surtout (voire uniquement) là pour palier à une défaillance matérielle. Alors que pour moi une sauvegarde est très souvent là aussi pour palier à une défaillance de l'utilisateur.
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 :
P.S. : Juste pour chipoter, au niveau des défaillances matérielles, le taux de panne d'un ordinateur est certes sans doute plus élevé [2] que le cumul des surtension/foudre/feu/inondation/cambriolage/tremblement de terre/explosions/etc. qui affectent tous les appareils d'un foyer. Mais c'est à mon avis presque comparable (des cambriolages, j'en ai vu beaucoup…). Pourtant sauvegarder sur son ordinateur c'est un « cache de sauvegarde » et sauvegarder sur son NAS c'est une « vraie sauvegarde ».
[1] je vais utiliser ce terme si cela calme un peu les ardeurs de certains
[2] Environ 2% pour l'HDD d'après Backblaze
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par ckyl . Évalué à 0.
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).
Maintenant tu fais l'analyse de risque que tu veux, ce sont tes données et je pense que tout le monde se fiche à la fois de risque que tu prends avec tes données et de savoir ce que toi tu penses de leur stratégie. En fait tu attends quoi de ce post ?
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . É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 :
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 3.
Alors défaillance de la machine encore jamais arrivé, si une fois tous les deux ans en moyennes un disque d'un des raid meurent (y en a 16 de 300Go par hyperviseur).
Les machines de sauvegardes sont pas dans le même bâtiment et n'héberge pas de serveur samba, ce sont elles (il y en a deux) qui se connecte sur les partages réseau pour faire les backup (une fois par heure en alternance entre mes deux machines de sauvegarde).
La rétention est de deux ans.
Pour restaurer un fichier il n'y a que deux personnes qui ont l'accès (depuis un pc sous linux) en fait c'est un accès sftp et le mot de passe est dans un coffre dans une banque (si on devenait indisponible).
Le plus gros incident à été le ransomwar locky, nous avons tous restauré les dégâts fait pas locky, depuis nous avons augmenté sérieusement notre sécurité en revoyant les droits sur les partages réseaux.
Comme soft de sauvegarde c'est rsnapshot.
Pour moi le plus important c'est:
1. La machine que vous sauvegardez ne doit pas avoir accès aux sauvegarde (c'est la machine de sauvegarde qui se connecte)
2. Tester les sauvegardes, ben oui il est déjà arriver d'avoir des bandes qui étaient illisible ou que le script de sauvegarde échoue.
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . Évalué à 1.
C'est intéressant mais tu aurais aussi quelques statistiques sur le nombre de fois où tu as fait appel aux sauvegardes suite à une erreur utilisateur ?
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 4.
une à deux fois par mois en moyenne
pour 170 ordinateurs (donc 80 qui sont de la bureautique le reste sont des ordinateurs industriel).
Certain n'ont jamais rien demandé d'autre sont de vrai abonnés.
80% sont du à une erreur (fichiers écrasé ou supprimé par erreur) 19% des "je comprends pas j'ai rien fait c'est pas de ma faute" et le reste corruption d'un fichier
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par SaintGermain . Évalué à 2.
Merci cela correspond à peu près à mon expérience aussi (au boulot). Mais cela m'étonne quand même qu'il n'y ait aucune panne de disque dur sur les ordinateur des utilisateurs (ou alors ils n'ont pas de disque dur ?).
Par contre vos utilisateurs ont beaucoup de chance : une sauvegarde toutes les heures, c'est vraiment un grand confort.
Mon admin me disait que d'aller au delà d'une sauvegarde par jour c'était très difficile techniquement (et pas rentable par rapport au besoin).
Par contre on sauvegardait tout le disque dur de chaque utilisateur, pas seulement les partages réseaux.
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 2.
Nous ne sauvegardons pas les postes clients, les utilisateurs ne sont pas autorisé à stocker des données sur leurs disques dur, si ils le font c'est leur problème.
Par contre le parc est hétérogène, ça veux dire 4 à 5 images de base différente, quand un disque d'un poste d'utilisateur lâche on repousse l'image de base dessus (avec clonezilla).
Mais c'est vrai que des pannes de disques c'est assez rare, depuis 2009 (quand je suis arrivé dans l'entreprise) je dois avoir pas plus de 20 disques dur qui sont mort (je suis à la maison j'ai la flemme de me connecter sur le glpi de l'entreprise pour compter).
Après je bosse dans une boite qui fait des consommables pour la machine outils, donc au niveau donnée ça va tous les fichiers tiennent sur 1.3To (pour faire une sauvegarde à rsnaphost il lui faut 40min), un fichier de programmation pour une cnc c'est entre 1ko et 5ko c'est du texte avec de l'iso dedans.
Après les autres sauvegardes (is-series(as400 erp), vm pour applications métier (compta, R&D, contrôle qualité, logistique …) sont fait uniquement une fois par nuit (mes hyperviseurs sont sous proxmox).
[^] # Re: Ne pas confondre sauvegarde et gestion de version
Posté par KiKouN . Évalué à 3.
Ha les utilisateurs, c'est super. Ça permet de rentabiliser le système de sauvegarde.
# Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 4.
Non, tu fais une équivalence un peu trop rapide. Tu compares la localité (dans les deux cas, copie locale vs. distante) et tu en conclus que c'est la même chose sur la finalité. Sauf que le fait d'avoir des dépôts locaux dans un DSCM n'a aucun but de sauvegarde, ça sert à ne pas avoir à joindre un dépôt distant pour effectuer des opérations. Une comparaison plus juste me paraîtrait être "j'ai une copie locale de ma sauvegarde chez Hubic (par exemple) histoire de pouvoir la restaurer sans devoir la télécharger". Si finalement elle est foutue aussi, bon bah faudra la DL, mais si non, tu gagnes du temps.
J'ai pas envie de réfléchir à est-ce que btrfs + raid1 à deux disques protège du bitrot. Simplement sur ce passage je pense que tu te trompes aussi. Dans les situations du genre :
du point de vue du RAID1 il ne verra que des couches supérieures qui lui envoient un ordre valide "enregistre-moi ces données sur la grappe stp" et s'exécutera, et tu n'auras plus rien. Dans un certain nombre de cas donc, notamment celui que tu revendiques comme "moi j'ai raison ils ont pas compris" ("RAID1 me sauvera d'un bug dans CoW qui décide de faire du Erase on Write"), non RAID1 ne fera rien pour toi.
Je pense que le « responsable de l'architecture informatique d'un grand groupe multinational avec un chiffre d'affaire de plusieurs milliards » est sans doute un gland (c'est le genre de titre censé donner de la crédibilité mais c'est marrant sur moi ça fait l'effet inverse) mais de ton côté tu as quelques raccourcis/lacunes/idées tranchées également, ça aide pas à se mettre de ton côté.
[^] # Re: Mes deux centimes
Posté par SaintGermain . Évalué à 1.
Ah bah cela fait plaisir d'avoir une critique posée et argumentée, merci beaucoup (quoique traiter l'autre de « gland », c'est pas très consensuel).
Là je ne saisis pas trop car pour moi mon « cache de sauvegarde » me sert justement à ne pas avoir à joindre ma sauvegarde distante pour effectuer des opérations.
Par exemple lorsque le WE je bidouille beaucoup, je fais un snapshot toutes les 5 minutes et je récupère souvent des fichiers par la suite (car je fais des erreurs en bidouillant). Ensuite je range, modifie et déplace pleins de gros fichiers (type photos/vidéos) et « lance une déduplication » pour optimiser les sauvegardes locales. À la fin du WE seulement je lance une synchronisation vers la sauvegarde distante.
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.
Je n'aime personnellement pas trop le terme « bit rot » qui est abusivement exclusivement associé aux « rayons cosmiques » qui n'arrivent en pratique jamais mais c'est le terme qui est souvent utilisé. Je préfère parler de corruption de données (non attribuable à l'utilisateur).
Mais sinon il n'y a rien de compliqué, en Btrfs RAID1 tu stockes deux fois les couples données+checksums. Lorsque le système détecte qu'un checksum n'est pas cohérent avec une donnée, il récupère le couple correspondant donnée+checksum sur l'autre disque (à condition bien sûr que ce soit cohérent sur l'autre disque).
Oui tout à fait, mon Btrfs RAID1 n'est pas du tout là pour gérer ce genre de situation. Il est uniquement là pour gérer la situation « fichier endommagé de quelques bits dû à un problème matériel » (i.e. corruption d'une donnée).
Pas du tout, je pense que tu n'as pas compris mon utilisation du Btrfs RAID1. Et j'ai justement souligné que le problème de mon approche est que je fais totalement confiance au CoW et que je n'ai aucune protection contre un mauvais fonctionnement du CoW (même la sauvegarde distante ne me protégera pas).
Si avec ce que j'ai écris plus haut, ma raison d'utiliser le Btrfs RAID1 n'est pas claire, je veux bien essayer de reformuler.
Je ne pense pas avoir d'avis totalement tranché et je me remets en question (d'où le journal d'ailleurs). Je suis pratiquement sûr en tout cas de ne pas être aussi agressif/hystérique dans mes commentaires que certains plus hauts.
[^] # Re: Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 6.
Note que c'est le tiers que toi non plus tu n'as pas l'air de beaucoup estimer que j'ai traité de gland.
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 (et encore moins une sauvegarde), donc même pas capable de vraiment permettre de développer et versionner son code dans l'absolu (puisque "bosser seul" n'est qu'un cas particulier de "bosser"), enfin en tout cas si je tombe dans une boîte où le CTO me sort que la référence c'est son dépôt local je serai content que le préavis en période d'essai soit de 24h la première semaine, ton « cache de sauvegarde » est un cache de la sauvegarde, pas la sauvegarde.
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 (en gros une suppression non malveillante d'un de tes fichiers, dont tu te rends compte assez rapidement (parce que j'imagine que tu vires des vieux snapshots au bout d'un moment vu que ton disque n'est pas infini), et pas du tout une défaillance matérielle / logicielle, ou une catastrophe type incendie). 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.
Attention ça sonnerait presque comme "je prépare ma sauvegarde en local et je la fais effectivement lorsque je l'envoie à distance" :-)
Alors là pardon mais peut-être est-ce ce que tu penses, mais c'est pas du tout ce que tu exprimes dans la phrase originale que je critique (et je suis pas le premier).
Je la remets :
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".
Franchement n'étant pas dans ton cerveau, je ne peux pas infirmer que tu t'es juste mal exprimé, mais répondre "j'ai jamais dit ça" et "je sais que le RAID1 ne me protège pas d'un problème de CoW" c'est un peu fort.
Je vais te dire ce que je pense être la cause de réactions un peu dures plus haut. D'autres ont relevé les quelques incohérences / lacunes que je pointe, ou d'autres supposées dont je n'ai pas les billes pour causer (j'ai dit que je voulais pas disserter sur est-ce que un RAID1 de deux disques protège du bitrot grâce aux checksums :-P). A cause de ces problèmes et de ta position quand même très tranchée, pardon, ça peut passer pour du Jayce en très soft bien sûr (si tu connais pas, en gros, un mec qui comprend rien à ce qu'il fait mais soutient mordicus qu'il a tout compris et le reste du monde est nul). Je sais que personnellement ça m'énerve, et je suis heureux que tu aies trouvé mes remarques posées parce que pour qui est familier de certaines de mes interventions sur DLFP, c'est pas toujours le cas, je fais des efforts là :-D
Pour caricaturer, imagine-toi face à un mec partisan de la théorie de la terre plate qui te répond que si la terre était ronde, les avions partiraient dans l'espace puisqu'ils volent tout droit. Ca peut énerver.
[^] # Re: Mes deux centimes
Posté par SaintGermain . É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
[^] # Re: Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 25 juin 2017 à 01:00.
Et justement, ce que je voulais dire dans mon message initial, c'est que l'analogie est douteuse car les buts sont vraiment différents (dans l'un, collaborer dans le temps (donc y compris avec le soi de dans un mois) sur des fichiers textes, dans l'autre se prémunir d'accidents).
Pour du code, très clairement (indiqué par ma menace de préavis de dém :-)) le seul dépôt accessible par quelqu'un d'autre que le mec qui a ses mains sur l'ordi (et accessoirement sauvegardé… :-D) donc github.
Bon là c'est moi qui ai été trop succinct, par "distant" je voulais vraiment regrouper tout ce qui ne repose pas sur la techno de ton ordi (CoW, RAID…) ni de son matériel (même disque), donc je comptais presque "un disque USB" dans distant. L'idée simplifiée étant toujours "si tu fais confiance au CoW c'est chaud".
Bon je veux bien t'accorder le bénéfice du doute sur le sens profond, mais je maintiens que c'est pas comme ça qu'on a été plusieurs à le comprendre (pour être plus précis, ton "apparemment" sonne vraiment ironique genre "je suis protégé grâce à ça mais apparemment ça compte pas") et je ne démordrai pas de cette interprétation :-)
Franchement, il y a en général besoin de vulgarisation dans le monde de l'informatique, mais là vu ton setup particulier et ta position plutôt à rebrousse-poil de l'idée établie sur le sujet débattu, je pense qu'en effet tu aurais du blinder ton discours.
[^] # Re: Mes deux centimes
Posté par SaintGermain . Évalué à 1.
Bien entendu on ne peut pas faire l'amalgame complet, ce sont quand même deux thèmes distincts. Mais quand je vois un outil comme bup qui est en gros git utilisé comme outil de sauvegarde (cf. ma réponse à steph1978 pour prouver que bup c'est grosso modo git), je me dis que les deux thèmes doivent partager beaucoup de choses en commun.
C'est dommage car on est passé à côté de la discussion sur la confiance au CoW dans toutes ses discussions.
Déjà pour mettre les choses au clair, le snapshot (CoW) est envoyé toutes les semaines sur le serveur distant. Donc à la fin de la semaine, j'ai quand même une copie physique distante.
Donc c'est pendant cette semaine où le snapshot est uniquement présent sur mon disque local, que se joue vraiment le risque.
Étant donné ces deux solutions :
Mon idée est justement que la première solution est
apparemmentpeut-être plus fiable que la deuxième.La première solution a comme avantage que si la carte mère et le kernel/FS marchent bien, on est sûr que la donnée n'est pas corrompue, autrement on peut perdre une semaine de données en cas de défaut [1]
La deuxième solution a comme avantage que si la carte mère ou le kernel/FS déconne, on a pas perdu la semaine de données. Par contre au niveau des inconvénients :
Donc l'analyse de risque que j'ai faite c'est que je n'ai jamais eu de problème ayant abouti à une perte de données utilisateur avec la carte mère et le kernel/FS. Par contre j'ai souvent eu des données corrompues (mauvais disque, mauvais câble).
Donc tout « naturellement » j'ai choisi la première solution. Je serais donc intéressé par les critiques sur mon raisonnement (et j'espère avoir été clair cette fois).
[1] Il y aussi le cas où un disque dur du RAID1 lâche et que le deuxième lâche aussi pendant la reconstruction du RAID1. Je ne sais pas à quel point c'est probable lorsque l'on a deux disques de marques différentes.
[^] # Re: Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 25 juin 2017 à 22:08.
Attention on te l'a dit plus haut, tu fais une erreur qui te conforte à tort dans ta comparaison : bup n'utilise pas git, il utilise le format de stockage de git mais d'une manière différente (c'est expliqué dans la doc de bup).
Oui donc en gros tout le monde est d'accord : tu fais une bonne sauvegarde, distante, une fois par semaine. Et en local t'as une assurance contre les rm intempestifs et le claquage d'un disque :-)
[^] # Re: Mes deux centimes
Posté par SaintGermain . Évalué à 1.
Pas vraiment d'accord, hormis pour les métadatas, bup est un git optimisé (nombre + taille des fichiers).
J'ai parcouru la doc de bup et j'ai mis les extraits plus haut (personne ne m'a répondu d'ailleurs).
Et il y a quand même cela dans la doc :
Et surtout la corruption de données. Ce « détail » n'est quasiment jamais pris en compte dans les solutions ou architecture de sauvegarde. Je ne sais pas si j'ai la poisse, mais rien que l'année dernière, cela m'est arrivé deux fois.
[^] # Re: Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 2.
Sans doute parce qu'en général la sauvegarde s'occupe d'avoir une copie des données (distante pour être vraiment efficace :-P bup te cause quand même de comment l'envoyer à distance, ta "sauvegarde locale" ;-)) et est considérée suffisamment orthogonale pour ne pas parler de protéger des aléas de la copie courante (et là y a RAID, les FS avec checksum…)
Le fait que l'outil ait un "sas" local ne valide pas pour moi la pertinence d'une sauvegarde locale contre autre chose qu'un bête rm (et avant que tu remettes sur le tapis à toutes les sauces les corruptions de bits, si ton disque commence à chier dans la colle sur les fichiers courants, il peut tout aussi bien chier dans la colle sur les fichiers de la sauvegarde locale, et si les deux sont corrompus… d'où la problématique orthogonale mais nécessaire aussi d'outils contre ça).
[^] # Re: Mes deux centimes
Posté par SaintGermain . Évalué à 1.
Je ne suis pas spécialiste de bup, mais il semble quand même que son fonctionnement standard c'est de faire une sauvegarde locale, de l'envoyer ensuite par rsync vers une sauvegarde distante et ensuite d'utiliser la sauvegarde locale. Par exemple ce n'est pas possible avec bup de faire un restore depuis la sauvegarde distante (ou bien il faut faire le restore depuis la sauvegarde locale ou bien se connecter sur la machine distante pour « opérer en local » pour peu que l'on ait bien tout installé sur la machine distante).
Cela ressemble quand même très très fortement à ce que je suis en train de faire. ;-)
C'est un peu à la frontière je te l'accorde, mais certains outils de sauvegarde comme bup (encore lui !) intègre la protection contre la corruption de données (via checksum effectué par l'outil même).
Là j'ai du mal à te suivre. Dans mon approche, les fichiers courants et les fichiers de la sauvegarde locale sont exactement les mêmes (reflink). Donc si l'un est corrompu, l'autre l'est automatiquement aussi. Mais j'ai justement un RAID1 pour empêcher que la donnée originale soit corrompue (et donc automatiquement la donnée localement sauvegardée). Donc sauf à considérer une erreur dans la carte mère ou le FS/Kernel, on peut dire que les données ne peuvent pas être corrompue dans mon approche.
Et pour la protection contre le bête rm, il y a un admin plus haut qui donne des statistiques sur l'utilisation de ses sauvegardes. En très très grand majorité, c'est suite à un bête rm qu'il utilise les sauvegardes. Donc cela ne me semble pas idiot d'optimiser mon approche pour me protéger contre le rm et de « négliger » un peu la protection contre les autres risques (même s'ils sont couverts en fin de semaine lors de la sauvegarde distante).
Merci pour la discussion posée ! C'est quand même sacrément plus agréable.
[^] # Re: Mes deux centimes
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 27 juin 2017 à 00:35.
Encore une fois il est évident que pour un certain volume de données (et même en fibre 1Gbps, plusieurs To ça se récupère pas en un claquement de doigt) il faut une copie locale pour opérer. Mais note que "j'ai moyen de mettre la main sur une copie locale" vient après et dépend de "j'ai une copie distante" dans les cas vol / incendie / assez de disques morts pour tuer le RAID.
Quand ton disque fou aura corrompu la copie courante et le backup local, tu seras heureux que bup te dise "ouh la le checksum est pas bon là !" :-)
Oui c'est par exemple de RAID dont je parle comme outil orthogonal à un outil de sauvegarde pour protéger des aléas que la sauvegarde ne traite pas.
On a à peu près jamais dit ça, juste qu'une sauvegarde ne traite classiquement pas de corruption mais de perte violente et accidentelle, ce que le RAID ne traite à peu près pas du tout (les flammes n'épargneront pas un de tes deux disques par respect pour le RAID), et que la formulation de ton journal pouvait laisser penser que tu prétendais avoir un système de sauvegarde complet avec tout dans une seule machine.
Je pense qu'on commence à tourner en rond donc je remets l'appel à l'armistice que j'avais déjà mis plus haut : dans ce fil j'ai l'impression qu'on est à peu près tous d'accord, même tes contradicteurs d'autres fils, à quelques détails près, et que ça repose principalement sur une question de formulation et de vocabulaire.
[^] # Re: Mes deux centimes
Posté par SaintGermain . Évalué à 1.
Ben justement si c'est le but. Si la donnée (et le backup local) est corrompu, je veux le savoir afin de ne pas écraser le backup distant. On peut faire cela avec un Btrfs RAID1 ou avec un utilitaire de sauvegarde intégrant une protection contre la corruption de données.
Si le dépôt local de bup est corrompu, bup va me dire "ouh la le checksum est pas bon là !" et c'est exactement ce que je souhaite (et que peu d'utilitaires de sauvegarde proposent).
Oui merci. J'ai bien compris que lorsque je parlerai de sauvegarde, il faut faire très très attention aux termes non techniques. À la limite pour éviter le bikeshedding, il vaut mieux éviter de vulgariser et entrer directement dans les détails techniques.
J'aurais fait un journal pour parler de Btrfs snapshot/send/receive et un journal pour parler de Btrfs RAID1 pour la protection contre les données corrompues, personne ne serait montée sur ses grands chevaux. Comme c'est deux notions complémentaires, cela ne m'a pas semblé illogique de combiner les deux dans mon journal. La grosse erreur ayant été d'oser parler de « sauvegarde locale » au lieu de simplement « snapshot » ou de « cache de sauvegarde ».
Enfin en conclusion grâce aux questions sur bup, j'ai trouvé pas mal de gens qui font comme moi (bup avec dépôt local + dépôt distant pour gérer les sauvegardes) donc cela me rassure sur mon approche.
# Sauvegarde, oui, durable, non
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Je suis étonné des mauvaises notes de certains commentaires que je trouve pourtant pertinent, en l’occurrence ceux qui expliquent qu'une vraie sauvegarde, c'est une copie sur un disque différent, voir sur un disque distant etc..
Il est probable que ceux qui pensent qu'ils ont tord, ou qu'ils sont trop paranoïaques, n'ont jamais eu de problèmes serieux de pertes de données sur une machine, et n'ont jamais réfléchi à l'impact sur leur vie pro et/ou perso de la suppression de tels ou tels fichiers. Ils devraient donc s'en inquiéter, parce que la chance que ça arrive, augmente avec le temps, c'est statistique.
Et puis, même si il faut "calibrer" la solution de sauvegarde avec le degré de criticité des données, quand on perd des données non critiques, sans sauvegarde, cette perte reste quand même super chiante.
Perso, j'ai fait en sorte que je puisse être opérationnel (professionnellement) en moins d'une heure max après la récupération d'un laptop qui fonctionne (suite à un vol, au crash d'un disque, suppression involontaire de donnée). Ce temps correspond au temps d'installation d'une distro + configuration du système avec Ansible + restauration des données. Ce qui nécessite donc une sauvegarde distante et non locale.
[^] # Re: Sauvegarde, oui, durable, non
Posté par SaintGermain . Évalué à 1.
Le commentaire « Même un ficher .bak est une sauvegarde » de gle est à +8, donc la plupart des gens considèrent sans doute que le terme « sauvegarde » n'est pas si exclusif que cela.
Si j'avais utilisé le terme « cache de sauvegarde » au lieu d'utiliser le terme « sauvegarde locale », je pense que j'aurais eu des commentaires beaucoup plus constructifs. C'est vraiment dommage de se braquer uniquement sur un terme comme cela.
Je répète ce que j'ai écris plus haut : « ceux qui font moins que moi sont des idiots et ceux qui font plus sont des paranoïaques ».
Ceux qui ne pensent pas comme toi ou qui font différemment ont peut-être leurs raisons. Il faudrait chercher à comprendre avant de porter un jugement.
Cela dépend des données non ? Par exemple je sauvegarde mes emails perso (un peu comme je stocke les cartes postales, je ne sais pas trop pourquoi) et ce n'est pas du tout critique. Si suite à une défaillance je perds les derniers emails perso…bah non ce n'est pas « super chiant ».
La « sauvegarde locale » ne peut s'envisager qu'à condition d'avoir aussi une « sauvegarde distante » (je l'ai répété plusieurs fois même si à priori ce n'était pas clair dans le journal). Donc ton argument tombe un peu à l'eau.
Le seul inconvénient c'est que la « sauvegarde distante » est rafraîchie toutes les semaines alors que la « sauvegarde locale » est rafraîchie tous les jours (voire toutes les 5 minutes).
Mais comme je ne peux pas me permettre de faire une « sauvegarde distante » toutes les 5 minutes, l'inconvénient n'en est pas réellement un.
[^] # Re: Sauvegarde, oui, durable, non
Posté par Sufflope (site web personnel) . Évalué à 1.
Hum non ce n'est pas le seul inconvénient, c'est une des différences (avec la localité, évidemment).
L'inconvénient qui en découle, c'est que si tu perds tout dans un incendie ou un bug ou ransomware ou…, tu perds une semaine au lieu de cinq minutes.
Cet inconvénient est aggravé, enfin, sa probabilité augmentée, par le fait que cette sauvegarde locale est non seulement locale géographiquement, mais même pas dans une autre machine, ni même un autre disque (et là on s'approche quand même du minimum de la notion de sauvegarde…), ni même un autre FS et ses outils, que la copie live !
[^] # Re: Sauvegarde, oui, durable, non
Posté par SaintGermain . Évalué à 1.
Non parce que techniquement cela n'aurait pas été possible de faire une sauvegarde distante toutes les 5 minutes (sauf à avoir une fibre de folie). Donc dans tous les cas j'aurais fait uniquement une sauvegarde distante par semaine.
Il faut voir cela sous l'angle du bonus. Un « cache de sauvegarde » c'est 100% du pur bonus, on a rien de moins et on a un petit peu en plus (quasiment rien pour certains, mais c'est toujours ça de pris).
[^] # Re: Sauvegarde, oui, durable, non
Posté par showtime . Évalué à 1.
Comment tu t'organises pour sauvegarder tes mails ?
Est-ce que tu copie le contenu de ton fichier .mbox ou de ton dossier maildir ?
Ou est-ce que tu utilises des outils comme OfflineIMAP ?
[^] # Re: Sauvegarde, oui, durable, non
Posté par SaintGermain . Évalué à 1. Dernière modification le 30 juin 2017 à 19:15.
En gros je fais un snapshot de mon /home qui contient entre autres tous les emails.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.