Problème disque dur sauvegarde

Support Debian
#1

Bonjour,
je suis sur une Debian 6.0.3, un serveur qui me sers de stockage et backup pour mon petit réseau local.
1 clé usb (boot via grub)1000MO
1 disque Sata (système + home)(a) 160GB
1 disque Sata (Fichiers de travail)(save1) 1000GB
1 disque Sata (Sauvegarde autres fichiers)(save2)1000GB
le tout géré, via webmin et ssh, pas de bureau ou autre, j’ai fais l’installe sur mesure pour mes besoins de stockage uniquement.

Ce matin en me connectant, via ssh dans un dossier de Save1, et voulant modifier un fichier, j’ai eu une erreur me disant que le dossier est en lecture seule.

Je redémarre le serveur, et la ata4.00 SRST FAILED (errno=-16).

J’ai déconnecté le disque Save2 et fdisk -l me donne:

[code]
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00037cdc

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1216 9764864 83 Linux
/dev/sda2 1216 19458 146523137 5 Extended
/dev/sda5 1216 1721 4051968 82 Linux swap / Solaris
/dev/sda6 1721 19458 142470144 83 Linux

Disk /dev/sdb: 1017 MB, 1017118720 bytes
255 heads, 63 sectors/track, 123 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 124 993226+ b W95 FAT32
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(123, 166, 63)[/code]

mon disque Save1, n’est pas détecté.

Que puis-je faire pour au moins le faire détecter et lancer une réparation?

Merci

#2

Salut,

Les connecteurs des disques sata sont généralement de très mauvaise qualité ! Je commencerais donc par aller voir si la connexion n’a pas bougée :slightly_smiling:

#3

Merci pour ta réponse,
je viens de reboot et le disque n’est pas détecté au niveau du bios, vous pensez que c’est mort?

#4

Re,

Je te dis de trifouiller les connecteurs !

#5

non, j’ai changé de cable sata et d’emplacement sur la carte mère et il est toujours non détecté.

#6

Je ne pense pas que ça sera mieux mais que donne un

fdisk -l

?

#7

fdisk -l:

[code]
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00037cdc

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1216 9764864 83 Linux
/dev/sda2 1216 19458 146523137 5 Extended
/dev/sda5 1216 1721 4051968 82 Linux swap / Solaris
/dev/sda6 1721 19458 142470144 83 Linux

Disk /dev/sdb: 1017 MB, 1017118720 bytes
255 heads, 63 sectors/track, 123 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 124 993226+ b W95 FAT32
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(123, 166, 63)[/code]

#8

cat /var/log/fsck/checkfs

[code]Tue Apr 23 14:44:13 2013

fsck from util-linux-ng 2.17.2
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb1
/dev/sdb1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

/dev/sda6: clean, 892/8904704 files, 1670926/35617536 blocks
fsck died with exit status 8
[/code]

#9

/etc/fstab: static file system information.

[code]#

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

proc /proc proc defaults 0 0

/ was on /dev/sdb1 during installation

UUID=e7b00117-dc17-49a4-b45d-550f44debcfe / ext3 errors=remount-ro 0 1

/home was on /dev/sdb6 during installation

UUID=df1de403-ab7d-4ad4-a5d5-dabfee33ec24 /home ext3 defaults 0 2

swap was on /dev/sdb5 during installation

UUID=a188808e-8f4d-4fb0-8acf-4e1424d92d14 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0

/dev/sdb1 /media/save1 ext3 defaults 0 1
/dev/sdc1 /media/save2 ext3 defaults 0 0[/code]

#10

Ce qui semble étrange c’est que dans fdisk-l, sdb correspond bien à ma cle usb (boot Grub) et

[code]#
proc /proc proc defaults 0 0

/ was on /dev/sdb1 during installation

/dev/sdb1 /media/save1 ext3 defaults 0 1
/dev/sdc1 /media/save2 ext3 defaults 0 0[/code]

il y a 2 fois sdb1 ??

#11

Non.

La partition mountée sur / était reconnu pendant l’installation comme sdb1. D’après le fdisk, elle est maintenant reconnu comme sda1.

#12

Je n’y comprends pas grand chose, mais ne pensez vous pas que les lecteurs on changé de nom?

#13

D’où l’utilisation de UUID dans fstab afin de monter les partitions même si elles ne sont pas reconnus sous le même nom.
Mais ça n’explique pas pourquoi un de tes disques n’est pas détecter. (Mais ça peut expliquer pourquoi les partitions d’un disque détecté ne sont pas mountées.)

#14

Re,

Si le bios ne détecte pas le disque, AUCUNE commande de ton OS, quel qu’il soit, ne pourra le concerner !

Après avoir vérifié la connexion SATA et la connexion alimentation, il te reste à essayer le disque sur une autre machine, puis faire ton deuil des données non sauvegardées contenue par ce disque :slightly_smiling:

#15

“Lecteur”, c’est de la terminologie DOS/Windows pour désigner un peu tout et n’importe quoi (disque, partition, système de fichiers…), ça n’existe pas sous Linux.

Les “disques” SCSI (ou vus comme tels par le noyau, comme les disques et clés USB, les disques SATA et PATA connectés à un contrôleur géré par un pilote libata, donc en gros tous avec les noyaux actuels) sont nommés dans l’ordre de leur détection par le noyau : premier disque détecté = sda, second disque détecté = sdb, etc. Ordre qui peut varier d’un démarrage à l’autre. Il n’y a plus de relation entre la connexion physique et le nommage contrairement à ce qui se passait avec les anciens pilotes ATA/IDE (maître sur le canal primaire = hda, esclave sur le canal primaire = hdb, maître sur le canal secondaire = hdc, etc.).

Si le disque “Save1” qui était auparavant sdb parce que détecté en second n’est plus présent, alors c’est le disque suivant, auparavant sdc, qui devient sdb. C’est aussi simple que ça. Comme le rappelle P’tit g, c’est aussi à cause de cette instabilité du nommage qu’il est recommandé de spécifier les systèmes de fichiers à monter par d’autres identifiants plus persistants que le nom de périphérique, comme le label ou l’UUID.

C’est faux. Ce qui compte, c’est si le noyau détecte le disque ou non.

#16

Salut,

Je serai content quand on me l’aura démontré.
Je sais fort bien que l’inverse n’est pas vrai et que ce n’est pas parce que le bios l’a détecté qu’il sera détecté par L’OS

#17

J’aurais dû préciser, c’est faux dans le cas général. Dans les exemples ci-dessous, le noyau peut voir et gérer des disques non vus par le BIOS :

  • disque ou clé USB sur un PC dont le BIOS trop vieux ne gère pas ces périphériques (j’en ai encore) ;
  • disque SCSI connecté à un contrôleur SCSI sans BIOS où dont le BIOS est désactivé ;
  • disque désactivé dans le BIOS, marqué comme “none” (astuce utilisée autrefois pour contourner le bug des BIOS qui plantaient avec les disques au-delà de 32 Gio).

En revanche si un disque était vu par le BIOS et ne l’est plus, alors il y a peu de chances que le noyau le voie. Problème matériel probable.