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).
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Ç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 ».
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.
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.
gestion de versions et sauvegarde de données me semble très similaire
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.
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).
« 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 »).
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 Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. É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 »)