Disparition de partition ext4 sur deux disques

Support Debian
#1

Bonjour,

Je possède un serveur sous Debian 8 personnel pour du stockage, de la virtualisation, serveur media… Bref, un serveur perso.
Mon problème est que cela fait 2 fois en 2 ans qu’il me perd des partitions en ext4.
Il y a 5 disques:

  • 1 SSD de 120Go pour le système
  • 1 DD de 2To Hitachi pour les sauvegardes
  • 1 DD de 1To Samsung pour les média et le stockage
  • 2 DD de 320Go Samsung en RAID 0 pour un dossier de partage sans importance.

Les disques dont les partitions ont disparus sont ceux de 1et 2To. Le serveur démarre tout seul tous les jours à 16h. Dans le syslog, lors du dernier démarrage, il apparait clairement que le système n’a pas pu monter les disques.
Tout les soirs, le serveur monte le disque de 2To et le synchronise par rsync avec le disque de 1 To. Et le démonte ensuite.

J’ai donc lancé un testdisk pour tenter de récupérer mes données, mais le programme me dit clairement que les disques ne possèdent plus de partitions.
Le plus ironique dans cette histoire c’est que mes vieux disques de 320Go en RAID 0 depuis 10 ans ne m’ont jamais posé problème!

Qu’est ce qui peut causer un tel problème de disparition de partition? De plus, sur deux disques totalement distincts?
Est ce que cela pourrait être un problème matériel?

Merci

#2

Rien de tel pour provoquer une usure prématurée de tous les composants.
Si c’est vraiment un serveur, il a été conçu pour tourner 24 heures sur 24.
Choisir de faire un redémarrage systématique à 16h ne me paraît pas très judicieux car perturbant pour les utilisateurs. Dans un environnement professionnel, par exemple, un serveur (de fichiers) sous Windows Server 2003 était redémarré chaque vendredi à 4h du matin. Ne me dites pas qu’avec une Debian vous ne pouvez pas faire aussi bien qu’avec Windows :cry:

Format des emplacements (2.5 " ou 5.25 "). Échangeables à chaud ? (j"en doute) Type d’attachement ?
Marque et référence du modèle de machine ?

Je vous suggère d’utiliser un montage à la demande (paquet autofs)
Pourrait-on avoir le retours de

lsblk
cat /etc/fstab
df -hTx tmpfs

Pouvez-vous expliquer comment cela se passe : entrées crontab ? Script utilisé ?

“monter” ou “détecter” les disques. Donnez les lignes exactes.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

Au cœur de Linux il y a un noyau. Au cœur de Windows, on trouve des pépins…

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

#3

Comme expliqué plus haut il s’agit d’un serveur personnel. Donc avec des composants grand publique. Et donc pas d’utilisateur à perturber.
Concernant l’usure prématurée, il y a mes 2 disques Samsung de 320Go chacun de plus de 10 ans montés en RAID0 qui eux ne souffrent d’aucun problèmes.

Quel avantage?

Un simple Rsync entre deux disque qui synchronise à l’identique le disque de 2To.[quote=“littlejohn75, post:2, topic:74773”]
“monter” ou “détecter” les disques. Donnez les lignes exactes.
[/quote]

Monter, car il explique qu’il ne trouve aucune partition sur ces disques la.

#4

ca sent le fstab sans l’ID des partitions

#5

Dis m’en un peu plus…
Mais les disques sont montés par un script, pas par le fstab. Et pour rappel, ni les disques en RAID O ni le SSD n’ont été impactés par le moindre problème

#6

c’est a toi de nous en dire plus, montre le script qui fait le mount

#7

Les disques étaient-ils partitionnés ? Si on n’a pas besoin de plusieurs partitions, on peut formater et monter directement le disque entier sans créer de table de partition ni de partitions.
Si oui, leurs tables de partition sont-elles encore présentes ? On peut les voir avec fdisk ?
Que disent blkid, file -s et wipefs quand on passé le nom d’un de ces disques en argument ?

#8

Pour moi, un serveur personnel cela n’existe pas, un majordome personnel à la rigueur.
Voici un exemple de serveurs avec un uptime de plus de 400 jours, des disques très anciens mais sans erreur, etc …

Une meilleure fiabilité. Un disque de sauvegarde (ou d’archives) n’a pas besoin d’être monté en permanence.
Si par exemple, la durée du montage normal est réduite à 5 minutes, le temps de faire un rsync incrémental, cela veut dire que le disque n’est accédé par le système moins de 0.35 % du temps. Autrement dit durant largement plus de 99 % du temps, les perturbations liées aux fluctuations de l’alimentation électrique, une coupure imprévue, etc … n’auront aucun effet sur votre disque de sauvegarde.

J’avais oublié de vous suggérer aussi d’utiliser LVM pour gérer les sauvegardes. Vous m’auriez aussitôt posé la question

et je vous aurais répondu qu’un système qui me laisse le choix de nommer les choses à ma convenance est préférable à mes yeux (par rapport à un système qui me dicte les nommages des volumes disques).
Si je peux avoir les sauvegardes d’octobre 2017 dans un périphérique bloc qui s’appelle /dev/svg_vg/oct2017_lv quel que soit l’emplacement du ou des disques physiques, je m’empare de cette possibilité et j’oublie la méthode ancienne : les sauvegardes d’octobre sont dans la partition x du disque de 4To qui a une étiquette bleue (et donc normalement c’est dans /dev/sddx à moins que suite à différentes manipulations le noyau énumère autrement les périphériques et choisisse /dev/sde ou autre ).

En combinant LVM et montage à la demande vous augmentez considérablement la fiabilité du processus, sans perdre en flexibilité, et vous avez quelque chose d’extensible : le groupe de volumes svg_vg peut s’étendre sur plusieurs disques physiques.

De plus, vous ne seriez pas tombé dans dans le piège de la mise à jour des UUID identifiants les “partitions”. (Si on pouvait voir le fstab)

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#9

Mon serveur fait tourner des services (Apache, VirtualBox, Owncloud, Plex… ) Il fait tourner des services et répond à des clients. C’est donc un serveur personnel.[quote=“littlejohn75, post:8, topic:74773”]
Une meilleure fiabilité. Un disque de sauvegarde (ou d’archives) n’a pas besoin d’être monté en permanence.
Si par exemple, la durée du montage normal est réduite à 5 minutes, le temps de faire un rsync incrémental, cela veut dire que le disque n’est accédé par le système moins de 0.35 % du temps. Autrement dit durant largement plus de 99 % du temps, les perturbations liées aux fluctuations de l’alimentation électrique, une coupure imprévue, etc … n’auront aucun effet sur votre disque de sauvegarde.

J’avais oublié de vous suggérer aussi d’utiliser LVM pour gérer les sauvegardes. Vous m’auriez aussitôt posé la question
[/quote]

Comme expliqué plus haut, le disque de sauvegarde n’est monté QUE lors du rsync et ensuite démonté. Cela ne revient-il pas au même que ce que vous proposez?

Je ne suis pas dan le désir de mettre en place un tel système de gestion de fichier. J’ai me rester cohérent et donc simple avec cette machine. Un simple rsync entre eux partitions ext4.

Le fstab est par défaut. je ne l’ai jamais modifié:

UUID=f862d9b5-0149-40c6-9e5f-32ff87053cec / ext4 errors=remount-ro 0 1
swap was on /dev/sda5 during installation
UUID=9bb90392-ac7b-4f0b-bbea-cb63ec8291a3 none swap sw 0 0

#10

Un simple mount /dev/sdd/ /mnt

Ah? Je pensais que créer une partition était indispensable. Du coup, cela pourrait pallier à mon problème?

#11

je pense que tu dois mettre tes labels car avec tes reboot a répétition tes ordres de partitions changes donc utilises le ID

https://linuxconfig.org/how-to-label-hard-drive-partition-under-linux

#12

Je doit etre chanceux mais cela ne m’arrive que très rarement :wink:

Mais il y a quelque chose de très très étrange. En fait les partitions ne semblent pas avoir été détruites. C’est comme si les données avaient simplement été supprimées. Du coup, lors de la synchro tous les soirs, je pense que le disque dont les données ont étés supprimées, a ensuite été synchronisé avec l’autre disque qui a tout naturellement tout supprimer puisque le rsync synchronise à l’identique.

Car je parviens à monter les disques ayant perdu les données sans problème et y écrire dessus. Un fdisk me remonte tous les disques présents sans erreur.

#13

C’est fortement recommandé (par moi) pour diverses raisons dont la lisibilité n’est pas la moindre, mais pas indispensable.

Si tu montes /dev/sdd (et pas /dev/sdd1) alors le disque n’est pas partitionné.

Surtout si elles n’ont jamais existé.

#14

En effet…

Oui, donc les données ont étés supprimées pour un raison que j’ignore encore. Je penche vers un problème matériel qui a mis le disque dans un etat instable qui lui a fait perdre les données qu’il contenait