SaintGermain a écrit 544 commentaires

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.

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.

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.

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 !

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).

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 :

1. Deux disques durs en Btrfs RAID1 et reflinker (i.e. copier avec CoW) la donnée sur le même FS
2. 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 !

Merci

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..

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.

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 […]

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.

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.

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 ».

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.

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.

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).

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.

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.

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.

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).

J'ai pas envie de réfléchir à est-ce que btrfs + raid1 à deux disques protège du bitrot.

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).

Simplement sur ce passage je pense que tu te trompes aussi. Dans les situations du genre :

ransomware qui chiffre le disque après avoir viré tes snapshots
toi qui fais des conneries genre virer tes snapshots, formatter ton FS…
CoW buggé qui fait des conneries

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.

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).

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.

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 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é.

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.

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 ?

Ensuite dire qu'avoir une « image locale » [1] n'apporte aucune économie, est un "surcoût" pur et n'a absolument aucun impact dans le contexte du risque, c'est aussi très réducteur.

Ca me semble parfaitement exact. Pour tous les risques non couverts par ton "cache" tu dois garder EXACTEMENT la même stratégie tu ne peux faire aucune économie. Comme ton "cache local" ne gère qu'un petit sous ensemble de cas (peut-être très fréquents) en pratique c'est bien un surcout (pour possiblement une plus grande souplesse dans les cas les moins graves).

Pour avoir exactement la même fonctionnalité (nombre et fréquence des sauvegardes sur mon serveur distant) sans « cache de sauvegarde », je devrais investir beaucoup plus dans mon réseau. Est-ce que donc ce n'est pas une économie de procéder de la sorte ? Pour moi si.

En fait tu attends quoi de ce post ?

• Que quelqu'un te dise que tu as découvert un truc fou ? Alors c'est aussi disruptif qu'un "rsync --link-dest" local, soit quelques décennies

J'aurais aimé deux choses :

1. Comprendre pourquoi ce genre de question provoque des réactions aussi extrêmes, brutales et parfois hystériques (après tout c'est une question technique, pas à propos de la politique ou sur la religion)
2. Avoir un débat plus orienté technique que rhétorique/philosophique parce que je trouve que les process de snapshots/send/receive et de déduplication et détection de corruption de données de Btrfs/ZFS sont très intéressants. Mais apparemment tout ce potentiel peut se résumer à "rsync --link-dest".

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 :

• Par exemple, faire un « cache de sauvegarde » est bien plus rapide qu'envoyer les données à distance (c'est instantané un snapshot) donc je sauvegarde bien plus souvent (voire même automatiquement après chaque installation/désinstallation de logiciels) même si je ne synchronise à distance que rarement. Au final ma sauvegarde distante a beaucoup plus d'historique et cela réduit le risque de perdre des données.
• Ou encore cela permet de faire de la déduplication beaucoup plus efficacement, donc il y a moins à envoyer par le réseau et du coup tu peux synchroniser vers le serveur distant plus souvent (j'ai fait un journal il y a quelques temps et je n'ai pas du tout été convaincu par les logiciels de sauvegarde effectuant de la déduplication à distance, i.e. non localement). Au final ma sauvegarde distante est plus à jour et cela réduit le risque de perdre des données.

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

Cela vient tout juste de m'arriver sous Firefox 52.2.0 (Debian Jessie) : page blanche lorsque je clique sur "Prévisualiser".
Je n'ai même pas réussi à me déconnecter : page blanche aussi.

J'ai laissé Firefox ouvert et j'ai lancé un Chromium : aucun soucis sous Chromium.

Du coup j'ai manuellement supprimé le cookie sous Firefox et je me suis reconnecté et ensuite cela remarche.

quand un utilisateur fait une erreur on restaure depuis les sauvegardes

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 ?

bup ne reprend pas un principe de gestion de configuration mais une technologie : packfile

Eh bien si on regarde comment bup fonctionne :
https://github.com/bup/bup/blob/master/DESIGN

On trouve ces infos intéressantes :

The purpose of bup is essentially to let you "replicate" data between two main data structures:
1. Your computer's filesystem;
2. A bup repository. (Yes, we know, that part also resides in your filesystem. […])

Essentially, copying data from the filesystem to your repository is called "backing stuff up,".
[…]
In short, a bup repository is a git repository.
[…]
[…] blobs, trees, commits, and refs, the four building blocks of a git repository. bup uses these four things, and they're formatted in exactly the same way as git does it, so you can use git to manipulate the bup repository if you want, and you probably won't break anything.
[…]
bup does use these tools a little bit differently than plain git. We need to do this in order to address two deficiencies in git when used for large backups, namely
a) git bogs down and crashes if you give it really large files;
b) git is too slow when you give it too many files;
c) git doesn't store detailed filesystem metadata.
[…]

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.

Bup reprend une technologie déjà utilisée par un logiciel de gestion de configuration […]. Mais c'est bien un logiciel de sauvegarde.

Ben c'est exactement ce que j'ai dit :

[…] la gestion de version peut aussi servir à sauvegarder ses données. C'est le principe de bup d'ailleurs […]

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).

Une sauvegarde protège contre une défaillance ou destruction de la machine (voir du site).

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).

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.

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.

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.

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.

Flûte je me suis trompé, pour l'énergie ce n'est pas l'USB qu'il me faut mais cela :

Donc il me faudrait un câble qui prennent ces deux connecteurs en entrées et qui partent vers un boîtier contenant mon disque dur.

Pour ma part je cherche quelque chose de plus inhabituel : un boîtier qui accepte en entrée une prise sata + usb (pour l'alimentation).

J'ai en effet ce genre de prise externe sur mon boîtier :

Est-ce que cela existe ?

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

Il te faut quoi de plus pour comprendre ?

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.

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 ?

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.

Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ?

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.

Écoute c'est très simple, j'ai fait un grep sur RAID sur les messages plus haut et j'ai trouvé :

mon disque est en RAID1 pour éviter les corruptions de données ou bit rot
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.

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.

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).

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.

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).

Ç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.

Quelqu'un peut-il trouver un moyen de lui faire comprendre ? Moi je n'y arrive pas.
Au secours…

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)…

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.

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.

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.

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.

Et ton fichier il faut le mettre dans chaque répertoire je suppose…Mmmmm

Où est le problème puisque tu dis avoir de quoi récupérer cette erreur (rm *) : gestion de version, backup, photorec, etc.

Parce que hier soir c'est arrivé peu de temps après ma dernière sauvegarde et que c'était des photos (donc pas de gestion de versions comme quand je tape du code).
Photorec marche bien mais renomme tous les fichiers et balance tout dans le désordre (adieu les répertoires).
Undelete a bien fonctionné et j'ai retrouvé mes fichiers, mais cela me donne des sueurs froides.

Donc une protection sur "rm *", ce serait un confort supplémentaire tout simplement.

Et prends moi pour un lapin de trois mois, il n'y a pas qu'avec la commande rm que tu dois certainement utiliser star. Perso je l'utilise à tout bout de champs. Et si j'appuyais sur Entrée souvent en lieu de star, je me poserais de sacrées questions. Après la taille des doigts toussa, on y peut rien, je te l'accorde.

Cela arrive rarement, mais pour les autres commandes que "rm", l'action est souvent réversible, donc ce n'est pas grave.
Ensuite je dois jongler avec pleins de layout différents, donc ce n'est pas facile de ne jamais faire d'erreur.

Ceci-dit la question n'est pas idiote, et trouver un moyen d'éviter de tout supprimer est ma foi une bonne chose. Du coup merci j'ai creusé. Le truc de prendre l'habitude de commencer par taper ls au lieu de rm (vu sur SO) est une très bonne idée. Un Oops ! vaut mieux qu'un Merde !.

Si je fais cela à chaque fois je vais devenir fou ! Pour moi, il faut juste que je peaufine le script bash plus haut et je serai satisfait !