Démontage d'une partition refusé par le système

Version imprimable

20/12/2023, 11h46
Jipété

Démontage d'une partition refusé par le système
Bonjour,

J'ai 3 partitions sur 3 disques dans ma machine, une par disque donc :
- sda1 pour le système,
- sdb1 pour les data,
- sdc1 pour les sauvegardes des data.
Je voudrais vérifier que les data sauvegardées sont bien disponibles en cas de pépin de sdb1, donc je me suis dit que j'allais démonter /dev/sdb1 pour ensuite examiner tranquillement le contenu de /dev/sdc1, d'accord ?

Le souci, sans doute lié à (cette cochonnerie de) systemd, c'est que quand je saisis la commande qui va bien, je me fais jeter...
Sous root (/data est le point de montage de /dev/sdb1) :
Code:

1 2 $ umount /data/ umount: /data/: la cible est active.
je suppose qu'il doit y avoir une (ou des) commande(s) cabalistique(s) et chamanique(s) pour libérer cette "cible active" et la rendre passive, mais laquelle ou lesquelles ?
(je dis ça car je n'ai pas activé de trucs bizarres prenant la main sur la partition, donc je ne sais pas d'où vient l'erreur, et rien dans dmesg, /var/log/syslog, message, kern.log).

Je n'ose pas faire man systemd car je n'ai pas ~~des heures~~ des jours devant moi...

Merci pour la piste,

EDIT : petit oubli, Linux Debian Bullseye 11.8 GTK2.8
20/12/2023, 12h50
gabriel21

Pour lister tout les fichiers ouvert d'une partition :

Code:

fuser -muv /ta_partition

Pour tuer sans lister (peut être dangereux et provoquer une perte de donnée) :

Code:

fuser -km /ta_partition/

Personnellement, je préfère fermer les documents ou fichier en question.:D
20/12/2023, 13h04
Sve@r

Bonjour

Citation:

Envoyé par Jipété

je suppose qu'il doit y avoir une (ou des) commande(s) cabalistique(s) et chamanique(s) pour libérer cette "cible active" et la rendre passive, mais laquelle ou lesquelles ?

En fait il faudrait plutôt comprendre ce qui pourrait être utilisé par "/data". Parce que le fermer "brut de pomme" c'est peut-être pas la meilleure idée. C'est un peu comme claquer une porte sur la tronche du type qui est derrière la porte.

Citation:

Envoyé par Jipété

Je voudrais vérifier que les data sauvegardées sont bien disponibles en cas de pépin de sdb1, donc je me suis dit que j'allais démonter /dev/sdb1 pour ensuite examiner tranquillement le contenu de /dev/sdc1, d'accord ?

Non pas d'accord. Pourquoi démonter sdb pour vérifier sdc ??? Il y a plein de méthodes de vérifications dont la première est de positionner des tests dans ta procédure de sauvegarde. Quand tu sauvegardes sdb sur sdc, tu checkes les opérations et surtout leurs codes de retour. C'est un peu une base, quand on fait quelque chose de sensible, que de vérifier que la chose est bien faite.
Ensuite si tu veux vérifier "après coup" ben tu peux par exemple, lors de la sauvegarde, lister le md5 de chaque fichier sauvegardé. Et pour la vérification tu vérifies le md5 des fichiers de sdc par rapport au md5 enregistré.
Autre méthode la plus drastique: tu bootes sur un DVD standalone (ex Slax) et là tu auras accès à sdb et sdc sans qu'elles aient été montées.
20/12/2023, 13h36
Jipété

Citation:

Envoyé par gabriel21

Pour lister tous les fichiers ouverts d'une partition :

Code:

fuser -muv /ta_partition

Ah merci ! Voilà la commande que j'attendais, et qui m'a montré des choses auxquelles je n'avais pas du tout pensé, et que j'ai proprement fermées, ensuite démontage sans souci de la partition de prod et examen de la partition de secours exactement comme si j'avais eu un problème avec les data.

Citation:

Envoyé par Sve@r

--snip--

En fait, je voulais faire comme si j'avais un vrai problème et, dans ces moments difficiles, compliqué de jouer avec la somme md5 ou autres trucs, là, il faut que la roue de secours soit opérationnenlle, ainsi que le cric et la manivelle, et c'est ce que je voulais tester.

Et le test est réussi, donc merci à vous et passez de bonnes fêtes, en attendant la nouvelle année, :mouarf:
20/12/2023, 13h55
Sve@r

Citation:

Envoyé par Jipété

En fait, je voulais faire comme si j'avais un vrai problème et, dans ces moments difficiles, compliqué de jouer avec la somme md5 ou autres trucs, là, il faut que la roue de secours soit opérationnenlle, ainsi que le cric et la manivelle, et c'est ce que je voulais tester.

Ah ok, test grandeur nature. Dans laquelle ta partition sdb a été perdue et que tu veux récupérer depuis sdc.
Dans ce cas de figure, en vraie situation, tu n'as plus de sdb donc plus de souci de démontage ou autre. Donc tu fais comme si ça arrivait vraiment: tu rebootes en mode single, là tu remplaces dans /etc/fstab le chemin de "data" qui pointe vers sdb (tu le fais pointer vers sdc) puis tu continues le boot et hop ça remarche comme avant.

Ce qui n'empêche pas aussi les vérifications "de contrôle" via md5 ou autre. En bref il y a 2 sortes de vérifs: les vérifs de bonne réussite de la sauvegarde et les vérifs pour checker si la sauvegarde jouera bien son rôle. Et les deux types de vérifs ne s'appréhendent pas de la même façon.
20/12/2023, 14h32
Jipété

Citation:

Envoyé par Sve@r

En bref il y a 2 sortes de vérifs: les vérifs de bonne réussite de la sauvegarde et les vérifs pour checker si la sauvegarde jouera bien son rôle. Et les deux types de vérifs ne s'appréhendent pas de la même façon.

Tutafait, mais quand même, l'une dépend de l'autre : la restauration dépend de la réussite de la sauvegarde et donc, je voulais vérifier que ce que je sais être présent dans /data se retrouve bien dans /dbck/sauvegarde/data, et à priori ça semble être le cas.

Donc tutti va bene, d'autant plus que de temps en temps (tous les quinze jours environ, plus rapproché si sujet critique), je recopie ce /dbck/sauvegarde/data sur un dd externe usb (deux en fait, en roulement : le rouge puis le vert puis le rouge etc.)

Et comme il m'est déjà arrivé d'être obligé d'aller récupérer dans le plus vieux des dd externes un fichier malencontreusement effacé, j'en conclus que cette partie est good.

Tout va bien, je vais pouvoir passer de bonnes fêtes.
Et vous aussi, lol !
:coucou: