Ça craint un peu. Moi j'utilise un SSD externe pour stocker mes VSTs (700Go) qui n'ont aucune raison d'être sur mon ordinateur principal (je ne fais pas de musique tous les jours). Donc si je venais à les perdre je pourrais toujours les réinstaller. Par contre vu la quantité de fichier, ça serait compliqué d'analyser l'inégrité à chaque fois que je m'en sers.
Mes backups de données sont faites sur des disque dur mécanique (2x4To sur un NAS et un disque dur externe de 4To qui copie le NAS).
J'aimerais encore une solution externe pour le cas malheureux de la perte totale physique (vol, incendie). Mais 4To en stockage à distance ça commence à chiffrer.
Ça coûte combien à la restauration ? Il me semble que sur ce genre d'offre tu as des frais lorsque tu ressors tes données (ce n'est pas une critique, il faut bien que le service soit payé, mais il faut le prendre en compte)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Stockage d'1To en glacier : ~€0.00254/GB/month * 1024 = 2.6€/TB/mois
Récupération d'1To en glacier (avec passage en "std") et en le laissant 3j sur le payant:
Restoring archived objects from the Glacier-class to the Standard-class €0.009/GB
One Zone - IA Object Storage €0,0000165/GB/hour ~€0.012/GB/month
gress fees* - inter regional or to Internet 75 GB free every month,
then €0.01/GB
Ce qui donne 0.009 * 1024 + 0.0000165*3*24 + 0.01*1024 = 19.45€/TB
Bref, a 3€ / mois pour la sauvegarde d'1To et 20€ la restauration, c'est pas cher. Et j'ai juste pris un fournisseur au hasard.
Et tu peux aussi faire des restauration partielles, en utilisant rclone + chiffrement du fichier. Tu as juste à demander la récupération des fichiers que tu souhaites
Et honnetement, meme une restauration à 100€, c'est pas énorme. En théorie, c'est pour le cas ou ton backup local meurt, donc cas qui n'arrive jamais.
En théorie, c'est pour le cas ou ton backup local meurt, donc cas qui n'arrive jamais.
Exactement, le glacier tu récupères les données quand tu as eu un incendie ou une inondation chez toi. C'est uniquement le "1" de 3-2-1 qui sert exactement à cette situation.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Probablement, car ce sont les mêmes technologies, et les cartes SD aussi.
Cependant, la densité de données est moindre sauf si la clé USB en question fait 1To), les transistors sont plus gros, et ils utilisent moins de niveaux de chare (un transistor va stocker 2 bits avec 4 valeurs de charge différentes, mais pas 3 bits avec 8 valeurs de charge). Ce qui laisse un peu plus de marge.
Sur les SSD les plus modernes, la différence entre un bit à 0 ou à 1 c'est un assez petit nombre d'électrons.
Pour les cartes SD au moins, il existe des cartes "industrielles" avec de la flash SLC (un seul bit par transistor) qui devraient mieux résister que les autres.
Il est important de faire la distinction entre les états alimentés et non alimentés, car le contrôleur SSD joue un rôle actif dans la préservation des données lorsque l'électricité est disponible. Lorsqu'un SSD est sous tension, le micrologiciel effectue des tâches de maintenance en arrière-plan, notamment le « nettoyage ». Le disque lit périodiquement les données, vérifie les erreurs de bits ou les dérives de tension et réécrit les cellules faibles pour rafraîchir leur charge. Cette gestion active réinitialise efficacement l'horloge de rétention, ce qui rend les SSD très fiables tant qu'ils font partie d'un système actif.
Une politique stricte consistant à mettre ces disques sous tension au moins une ou deux fois par an est nécessaire pour permettre au micrologiciel de rafraîchir les cellules NAND.
Il est également conseillé de les stocker au frais (et au sec j'imagine…). Les SSD, c'est comme les légumes…
Enfin, pour le stockage mieux vaut un SSD Single Cell (tension low ou high pour 0 ou 1) plutôt qu'un Quad Level Cell où chaque cellule stocke 4 bits : le contrôleur doit être capable de distinguer 16 niveaux de tension dans la cellule ! Et on n'arrête pas le progrès puisque Wikipedia annonce :
Penta-level cell or PLC (5 bits per cell) – currently in development
Donc 32 niveaux de tension :-/
Enfin la norme JEDEC semble plus exigeante pour les SSD grand public (doit conserver les données un an à 30°C) que pour les SSD d'entreprise (trois mois à 40°C).
Le scrubing peut être automatique, mais tu peux aussi le provoquer en lisant tout avec un dd if=/dev/sdcxx of=/dev/null bs=64M
Le système va lire les cellules et les réécrire en cas d'erreur, il y a toujours des bits de FEC dans une mémoire flash, faut-il encore qu'il y ai une relecture.
Posté par BAud (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 02 décembre 2025 à 18:17.
o_O c'est lisible pourtant :/
if=ce que tu lis
of= ce que tu écris, là : rien, tu ne voulais que lire (c'est le périphérique qui se charge des corrections nécessaires)
bs=taille du bloc de chaque lecture/écriture, tu prends un multiple de 2 généralement
Posté par MicP .
Évalué à 2 (+1/-0).
Dernière modification le 02 décembre 2025 à 19:22.
…/dev/sdcxx …
les deux xx sont en trop. C'est sans doute une petite erreur de frappe (peut-être à force d'habitudes :) )
Il vaudra mieux faire la lecture de TOUT le disque (accessible par /dev/sdc) plutôt que seulement une de ses partitions.
Pour savoir quel est le nom du fichier de périphérique qui permet d'accéder au disque que tu veux traiter,
tu peux utiliser udisksctl avec sa commande status :
mic@deb12x:~$ udisksctl status
MODEL REVISION SERIAL DEVICE
--------------------------------------------------------------------------
Samsung SSD 870 QVO 1TB SVQ02B6Q S5SVNF0R491094P sda
mic@deb12x:~$
Le nom du fichier de périphérique qui permet d'accéder à mon disque dur est dans la colonne DEVICE, dans laquelle on peut lire sda
et comme les fichiers de périphérique sont créés dans le répertoire /dev/ alors le chemin d'accès à ce fichier de périphérique sera : /dev/sda
Dans la colonne SERIAL, on trouve le numéro de série du disque qui est souvent indiqué aussi sur l'étiquette qui est collée sur le boîtier du disque
ce qui permet de savoir de quel disque il s'agit quand on en a plusieurs de la même marque, même modèle, etc.
Cordialement.
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
Posté par MicP .
Évalué à 2 (+1/-0).
Dernière modification le 02 décembre 2025 à 22:20.
Si on voulait lire tout un disque de 1TB, à coup de 512 octets, ça ferait 1024*1024*1024*1024/512 = 2147483648 opérations de lecture
Alors qu'à coups de 64Mio, il ne faudra que 1024*1024/64 = 16384 opérations de lecture.
=======
la valeur optimale du paramètre bs dépends de beaucoup de facteurs (matériels et logiciels).
Voici un extrait du rapport (gparted_details.htm) créé par GParted dans lequel on peut voir comment il fait
pour savoir quelle est la taille optimale du bloc à utiliser pour pouvoir faire la copie d'une partition d'une clef USB vers un disque.
(ici, le disque est en fait un fichier qcow2 qui est connecté à une machine virtuelle)
…
déterminer la taille de bloc optimale
copie de 16.00 Mio en utilisant une taille de bloc de 1.00 Mio 00:00:01 ( SUCCÈS )
16.00 Mio sur 16.00 Mio copiés
1.31393 secondes
copie de 16.00 Mio en utilisant une taille de bloc de 2.00 Mio 00:00:02 ( SUCCÈS )
16.00 Mio sur 16.00 Mio copiés
1.34249 secondes
copie de 16.00 Mio en utilisant une taille de bloc de 4.00 Mio 00:00:01 ( SUCCÈS )
16.00 Mio sur 16.00 Mio copiés
1.27943 secondes
copie de 16.00 Mio en utilisant une taille de bloc de 8.00 Mio 00:00:01 ( SUCCÈS )
16.00 Mio sur 16.00 Mio copiés
1.4216 secondes
copie de 16.00 Mio en utilisant une taille de bloc de 16.00 Mio 00:00:01 ( SUCCÈS )
16.00 Mio sur 16.00 Mio copiés
1.22036 secondes
la taille optimale de bloc est 16.00 Mio
…
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
# SSD uniquement pour du volatile
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
Ça craint un peu. Moi j'utilise un SSD externe pour stocker mes VSTs (700Go) qui n'ont aucune raison d'être sur mon ordinateur principal (je ne fais pas de musique tous les jours). Donc si je venais à les perdre je pourrais toujours les réinstaller. Par contre vu la quantité de fichier, ça serait compliqué d'analyser l'inégrité à chaque fois que je m'en sers.
Mes backups de données sont faites sur des disque dur mécanique (2x4To sur un NAS et un disque dur externe de 4To qui copie le NAS).
J'aimerais encore une solution externe pour le cas malheureux de la perte totale physique (vol, incendie). Mais 4To en stockage à distance ça commence à chiffrer.
AI is a mental disorder
[^] # Re: SSD uniquement pour du volatile
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
1 To en "glacier", c'est 3€/mois.
"La première sécurité est la liberté"
[^] # Re: SSD uniquement pour du volatile
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6 (+5/-1).
Ça coûte combien à la restauration ? Il me semble que sur ce genre d'offre tu as des frais lorsque tu ressors tes données (ce n'est pas une critique, il faut bien que le service soit payé, mais il faut le prendre en compte)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: SSD uniquement pour du volatile
Posté par Toto . Évalué à 7 (+6/-0).
En prenant les tarifs chez Scaleway (https://www.scaleway.com/fr/tarifs/storage/ ), tu as:
Stockage d'1To en glacier : ~€0.00254/GB/month * 1024 = 2.6€/TB/mois
Récupération d'1To en glacier (avec passage en "std") et en le laissant 3j sur le payant:
Restoring archived objects from the Glacier-class to the Standard-class €0.009/GB
One Zone - IA Object Storage €0,0000165/GB/hour ~€0.012/GB/month
gress fees* - inter regional or to Internet 75 GB free every month,
then €0.01/GB
Ce qui donne 0.009 * 1024 + 0.0000165*3*24 + 0.01*1024 = 19.45€/TB
Bref, a 3€ / mois pour la sauvegarde d'1To et 20€ la restauration, c'est pas cher. Et j'ai juste pris un fournisseur au hasard.
Et tu peux aussi faire des restauration partielles, en utilisant rclone + chiffrement du fichier. Tu as juste à demander la récupération des fichiers que tu souhaites
Et honnetement, meme une restauration à 100€, c'est pas énorme. En théorie, c'est pour le cas ou ton backup local meurt, donc cas qui n'arrive jamais.
[^] # Re: SSD uniquement pour du volatile
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0).
Exactement, le glacier tu récupères les données quand tu as eu un incendie ou une inondation chez toi. C'est uniquement le "1" de 3-2-1 qui sert exactement à cette situation.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: SSD uniquement pour du volatile
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
J'ai pas dit que c'était cher : je disais juste que le coût ce n'est pas que le stockage par moi.
Je suis d'accord que payer 100€ - même 1000€ en cas d'incendie c'est ok (pour une boîte en tout cas)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Clés USB
Posté par Indrik . Évalué à 5 (+5/-0).
Les clés USB non alimentées, perdent-elles lentement leurs données ?
[^] # Re: Clés USB
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Probablement, car ce sont les mêmes technologies, et les cartes SD aussi.
Cependant, la densité de données est moindre sauf si la clé USB en question fait 1To), les transistors sont plus gros, et ils utilisent moins de niveaux de chare (un transistor va stocker 2 bits avec 4 valeurs de charge différentes, mais pas 3 bits avec 8 valeurs de charge). Ce qui laisse un peu plus de marge.
Sur les SSD les plus modernes, la différence entre un bit à 0 ou à 1 c'est un assez petit nombre d'électrons.
Pour les cartes SD au moins, il existe des cartes "industrielles" avec de la flash SLC (un seul bit par transistor) qui devraient mieux résister que les autres.
[^] # Re: Clés USB
Posté par Craig77 . Évalué à 4 (+3/-0).
Il existe aussi des clefs USB en SLC, difficiles à trouver certes.
[^] # Re: Clés USB
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Oui, c'est électro-magnétique.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# solution ?
Posté par antistress (site web personnel) . Évalué à 7 (+4/-0).
Est-ce qu'il suffit de les brancher de temps à autre ?
[^] # Re: solution ?
Posté par antistress (site web personnel) . Évalué à 10 (+8/-0).
[^] # Re: solution ?
Posté par vmagnin (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Et vers la fin de l'article :
Il est également conseillé de les stocker au frais (et au sec j'imagine…). Les SSD, c'est comme les légumes…
Enfin, pour le stockage mieux vaut un SSD Single Cell (tension low ou high pour 0 ou 1) plutôt qu'un Quad Level Cell où chaque cellule stocke 4 bits : le contrôleur doit être capable de distinguer 16 niveaux de tension dans la cellule ! Et on n'arrête pas le progrès puisque Wikipedia annonce :
Donc 32 niveaux de tension :-/
Enfin la norme JEDEC semble plus exigeante pour les SSD grand public (doit conserver les données un an à 30°C) que pour les SSD d'entreprise (trois mois à 40°C).
[^] # Re: solution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Le scrubing peut être automatique, mais tu peux aussi le provoquer en lisant tout avec un dd if=/dev/sdcxx of=/dev/null bs=64M
Le système va lire les cellules et les réécrire en cas d'erreur, il y a toujours des bits de FEC dans une mémoire flash, faut-il encore qu'il y ai une relecture.
"La première sécurité est la liberté"
[^] # Re: solution ?
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0).
Merci
Tu veux bien me détailler le rôle de chaque partie de la commande que je comprenne bien ?
[^] # Re: solution ?
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 02 décembre 2025 à 18:17.
o_O c'est lisible pourtant :/
if=ce que tu lis
of= ce que tu écris, là : rien, tu ne voulais que lire (c'est le périphérique qui se charge des corrections nécessaires)
bs=taille du bloc de chaque lecture/écriture, tu prends un multiple de 2 généralement
et dd lit jusque la fin du périphérique
[^] # Re: solution ?
Posté par MicP . Évalué à 2 (+1/-0). Dernière modification le 02 décembre 2025 à 19:22.
Il vaudra mieux faire la lecture de TOUT le disque (accessible par /dev/sdc) plutôt que seulement une de ses partitions.
Pour savoir quel est le nom du fichier de périphérique qui permet d'accéder au disque que tu veux traiter,
tu peux utiliser udisksctl avec sa commande status :
Le nom du fichier de périphérique qui permet d'accéder à mon disque dur est dans la colonne DEVICE, dans laquelle on peut lire sda
et comme les fichiers de périphérique sont créés dans le répertoire /dev/ alors le chemin d'accès à ce fichier de périphérique sera : /dev/sda
Dans la colonne SERIAL, on trouve le numéro de série du disque qui est souvent indiqué aussi sur l'étiquette qui est collée sur le boîtier du disque
ce qui permet de savoir de quel disque il s'agit quand on en a plusieurs de la même marque, même modèle, etc.
Cordialement.
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: solution ?
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0).
Ok merci à tous deux
Et le paramètre bs=64M il est choisi comment ?
[^] # Re: solution ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
man dd dit
mais comme on écrit dans /dev/null je pense que grosso modo on s'en balance.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: solution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 04 décembre 2025 à 09:12.
Oula non, sans une écriture en "batch", la commande devient hyper lente.
"La première sécurité est la liberté"
[^] # Re: solution ?
Posté par MicP . Évalué à 2 (+1/-0). Dernière modification le 02 décembre 2025 à 22:20.
Si on voulait lire tout un disque de 1TB, à coup de 512 octets, ça ferait 1024*1024*1024*1024/512 = 2147483648 opérations de lecture
Alors qu'à coups de 64Mio, il ne faudra que 1024*1024/64 = 16384 opérations de lecture.
=======
la valeur optimale du paramètre bs dépends de beaucoup de facteurs (matériels et logiciels).
Voici un extrait du rapport (gparted_details.htm) créé par GParted dans lequel on peut voir comment il fait
pour savoir quelle est la taille optimale du bloc à utiliser pour pouvoir faire la copie d'une partition d'une clef USB vers un disque.
(ici, le disque est en fait un fichier qcow2 qui est connecté à une machine virtuelle)
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.