Différences

Ci-dessous, les différences entre deux révisions de la page.

--- start [2015/06/07 18:07] – [Besoins de Stockage Online] lcdvasrm
+++ start [2024/09/23 12:58] (Version actuelle) – [Besoins de Stockage Offline] lcdvasrm
@@ Ligne 14: / Ligne 14: @@
 ===== Recommandations générales du GIS-DON concernant la préservation à long terme des données numériques (textes, documents, photos, enregistrements sonores, vidéos, etc.) =====
 [[:ltdsp:media:gis_don:recommandations|Recommandations]] du GIS-DON \\
-Source : http://www.lne.fr/fr/r_et_d/gis-don/conservation-donnees-numeriques-gis-don.asp \\
+Source : https://www.lne.fr/fr/projets/gis-spadon \\
 En trois documents, le GIS-DON fait une présentation de la problématique. Ils permettent de réaliser le coût et les efforts associés au stockage numérique.
   * {{:ltdsp:media:le-numerique-ephemere.pdf|}} local : [[:ltdsp:media:gis_don:le_numerique_ephemere|le numérique ephémère]] du GIS-DON
@@ Ligne 23: / Ligne 23: @@
 Tu as plusieurs besoins classiques de stockage offline
-  - trouver un [[ltdsp:media|media de stockage]] capable de stocker de façon pérenne.
+  - trouver un **[[ltdsp:media|media de stockage]]** capable de stocker de façon pérenne.
       - Il doit pour cela être assez résistant à l'usure du temps mais aussi à tout un tas de facteurs environnementaux
         -  chaleur
@@ Ligne 31: / Ligne 31: @@
         -  champs magnétiques
         -  impulsions électromagnétiques
-  - être [[ltdsp:destruction|résistant à la destruction catastrophique]] comme le feu, tsunami ou tremblement de terre.
+  - être **résistant à la destruction catastrophique** comme le feu, tsunami ou tremblement de terre. Seule solution : **des copies situées en plusieurs sites suffisamment éloignés**.
   - il doit exister sur le long terme des [[ltdsp:readers|matériels en mesure de lire le train binaire du média de stockage]]
     - ou alors, [[ltdsp:media:integrated_readers|le media de stockage contient le reader]]. C'est l'idéal pour des projets très ambitieux avec une perspective à très long terme (type time capsule). Mais ce n'est probablement pas très adapté pour du stockage pérenne sur seulement 50 ans et moins.
-  - le [[ltdsp:fileformats|format des fichiers]] doit rester compréhensible par les futures générations de logiciels.
+  - le **[[ltdsp:fileformats|format des fichiers]]** doit rester compréhensible par les futures générations de logiciels.
 Quel que soit le niveau de qualité de chaque support, il est possible de répondre à toutes ces contraintes, mais à chaque fois avec un coût particulier.
@@ Ligne 69: / Ligne 69: @@
 Le problème est que ces liens vont être beaucoup plus dynamiques que les fonds eux même. Un archivage définitif ne me semble pas possible. Cela nécessite réflexion. FIXME \\
-Liens hypertexte : En fait, aujourd'hui, la meilleure solution que je connaisse est un Wiki de type Dokuwiki. Technologie KISS idéale. Pas de base de données. Tout le contenu n'est tout simplement qu'un ensemble de fichiers texte. Ceci est un Dokuwiki. Je suis assez confiant sur la pérennité de cette technologie tellement elle est géniale. Elle est open source, elle permet un travail collaboratif. Ça permet de faire l'équivalent de Wikipedia. Mais il faut très bien en border l'utilisation. Il y a bien sur des limitation qui apparaissent à partir d'une certaine taille de wiki. Je ne sais pas trop combien de pages max on peut espérer pouvoir gérer efficacement. Backuper un Dokuwiki est très simple, il suffit de recopier quelques répertoires bien identifiés et toujours le mêmes. Pas grand chose en somme. FIXME\\
+Liens hypertexte : En fait, aujourd'hui, la meilleure solution que je connaisse est un Wiki de type Dokuwiki. Technologie KISS idéale. Pas de base de données. Tout le contenu n'est tout simplement qu'un ensemble de fichiers texte. Ceci est un Dokuwiki. Je suis assez confiant sur la pérennité de cette technologie tellement elle est géniale. Elle est open source, elle permet un travail collaboratif. Ça permet de faire l'équivalent de Wikipedia. Mais il faut très bien en border l'utilisation. Il y a bien sur des limitation qui apparaissent à partir d'une certaine taille de wiki. Je ne sais pas trop combien de pages max on peut espérer pouvoir gérer efficacement. Backuper un Dokuwiki est très simple, il suffit de recopier quelques répertoires bien identifiés et toujours le mêmes. Pas grand chose en somme.\\
@@ Ligne 83: / Ligne 83: @@
     *le provider s'en charge, en offrant une interface FTP typiquement. Dans 50 ans ce sera peut-être un autre protocole, mais peu importe, on pourra encore télécharger le contenu.
   -le format des fichiers doit rester compréhensible par les futures générations de logiciels.
-    * Au pire cela pourrait se faire par une étape de conversion de formats de fichiers (de l'archive offline) avant upload online. L'espoir étant que, dans la mesure où les formats de fichiers d'origine sont simples, la conversion doit être faisable assez facilement. FIXME
+    * Au pire cela pourrait se faire par une étape de conversion de formats de fichiers (de l'archive offline) avant upload online. L'espoir étant que, dans la mesure où les formats de fichiers d'origine sont simples, la conversion doit être faisable assez facilement.
   -faible coût de gestion par an.
-    *Devrait se limiter à l'abonnement à un provider. Mais ça peut vite grimper si la taille du fond dépasse les 500Mo. FIXME
+    *Devrait se limiter à l'abonnement à un provider. Mais ça peut vite grimper si la taille du fond dépasse les 500Mo.
 Conclusion : pas de point problématique. A part peut-être le coût de gestion par an.
@@ Ligne 99: / Ligne 99: @@
 ===== Règles de nommage des fichiers et répertoires =====
 Afin d'accroitre au maximum la pérennité des noms de fichiers et des noms de répertoires, voici quelques [[ltsdp:nommage|propositions]]
+===== Nommages et organisation des fichiers pour les outils de traitement automatique =====
+[[ltsdp:nommage#organisation|propositions]]
 ===== Encore une fois, des règles basiques à respecter =====