Je suis la procédure décrite ici https://help.ovhcloud.com/csm/fr-vps-using-automated-backups?id=kb_article_view&sysparm_article=KB0047757
La commande lsblk m'indique bien un nouveau sdb:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 3.3G 0 loop /var/tmp
/tmp
sda 8:0 0 75G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 200M 0 part /boot/efi
├─sda3 8:3 0 1G 0 part /boot
└─sda4 8:4 0 73.8G 0 part /
sdb 8:16 0 76G 0 disk
├─sdb1 8:17 0 1M 0 part
├─sdb2 8:18 0 200M 0 part
├─sdb3 8:19 0 1G 0 part
└─sdb4 8:20 0 73.8G 0 part
Je crée le répertoire:
sudo mkdir -p /mnt/restore
ensuite
sudo mount /dev/sdb4 /mnt/restore
me renvoie:
mount: /mnt/restore: wrong fs type, bad option, bad superblock on /dev/sdb4, missing codepage or helper program, or other error
Une recherche en Copilot semble indiquer que:
Tu es exactement dans le cas classique où le disque du backup automatique est bien attaché (sdb), mais la partition principale (sdb4) ne se monte pas, car elle n’est pas dans un format directement montable.
Ce n’est pas une erreur de ton serveur : c’est le fonctionnement normal des backups automatiques OVH.
Pourquoi /dev/sdb4 ne se monte pas ?
Les backups automatiques OVH ne sont pas des copies brutes du disque.
Ils sont stockés sous forme d’image LVM interne, et la partition principale contient un LVM PV (Physical Volume), pas un système de fichiers directement montable.
Donc :
/dev/sdb4n’est pas un système de fichiers → d’où l’erreur wrong fs type- Il faut activer LVM pour voir les volumes logiques internes
- Ensuite seulement, tu pourras monter le volume logique contenant
/
Est-ce vraiment la piste à suivre? Donc la procédure d'OVH n'est pas complète?
Merci d'avance!
39712 
26.05.2023 13:36
Bonjour,
OK donc système de fichier XFS et non du EXT4 et encore moins de la gestion logique LVM comme le supposé l'IA.
Donc dans votre cas mount échoue à cause d'un doublon de UUID (vous devriez avoir d'autre logs qui vous l'indique)
Solution temporaire :
mount -o nouuid /dev/sdb4 /mnt/restoreSource : https://access.redhat.com/solutions/5494781
Note : une IA est "débile" et pas faire des supposition avec ce que vous lui donner, donc moins elle a d'infos plus elle vous dira "de le merde" mais en étant très sure d'elle.
Exemple sur cette partie qui est du pure FAKE :
Les backups automatiques OVH ne sont pas des copies brutes du disque.Ils sont stockés sous forme d’image LVM interne, et la partition principale contient un LVM PV (Physical Volume), pas un système de fichiers directement montable.
Cordialement, janus57
Bonjour,
Déjà on va commencer par les questions de bases :
1 - Quel est votre OS ?
2 - Quel est votre système de fichier ?
3 - Que donne la commande
blkid /dev/sdb4?Cordialement, janus57
Bonjour Janus,
Merci pour votre réaction rapide. Voici les réponses:
1) J'ai un almalinux v9.7.0 avec un WHM/cPanel.
2) # lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 ext3 1.0 38a62076-3ba6-4f42-9148-c995a235e623 3G 0% /var/tmp
/tmp
sda
├─sda1
├─sda2 vfat FAT16 20A1-E163 192.4M 4% /boot/efi
├─sda3 xfs 3f0c8f89-c97c-4626-8037-0b29884e751d 742.1M 23% /boot
└─sda4 xfs 21114daa-c867-4340-97b6-9343d05891b6 60.9G 17% /
sdb
├─sdb1
├─sdb2 vfat FAT16 20A1-E163
├─sdb3 xfs 3f0c8f89-c97c-4626-8037-0b29884e751d
└─sdb4 xfs 21114daa-c867-4340-97b6-9343d05891b6
3) /dev/sdb4: UUID="21114daa-c867-4340-97b6-9343d05891b6" TYPE="xfs" PARTLABEL="root" PARTUUID="50f046b0-39b9-4484-8968-d132c5081e25"
bav,
Hugues
Bonjour,
OK donc système de fichier XFS et non du EXT4 et encore moins de la gestion logique LVM comme le supposé l'IA.
Donc dans votre cas mount échoue à cause d'un doublon de UUID (vous devriez avoir d'autre logs qui vous l'indique)
Solution temporaire :
mount -o nouuid /dev/sdb4 /mnt/restoreSource : https://access.redhat.com/solutions/5494781
Note : une IA est "débile" et pas faire des supposition avec ce que vous lui donner, donc moins elle a d'infos plus elle vous dira "de le merde" mais en étant très sure d'elle.
Exemple sur cette partie qui est du pure FAKE :
Les backups automatiques OVH ne sont pas des copies brutes du disque.Ils sont stockés sous forme d’image LVM interne, et la partition principale contient un LVM PV (Physical Volume), pas un système de fichiers directement montable.
Cordialement, janus57
Un grand merci janus!
C'est bien parce que je doutais de cette reponse IA que je me suis tourné vers la communauté. J'ai bien fait!
C'est vrai que les réponses IA semblent convainquantes mais tout à fait à coté de la plaque.
Pour en revenir à la raison de l'erreur, j'imagine qu'un backup automatique/snapshot aura toujours les mêmes UUID:
/dev/sda4: UUID="21114daa-c867-4340-97b6-9343d05891b6" TYPE="xfs" PARTLABEL="root" PARTUUID="50f046b0-39b9-4484-8968-d132c5081e25"
/dev/sdb4: UUID="21114daa-c867-4340-97b6-9343d05891b6" TYPE="xfs" PARTLABEL="root" PARTUUID="50f046b0-39b9-4484-8968-d132c5081e25"
Si oui, les instructions d'OVH devraient être adaptées comme vous me m'avez suggéré. Est-ce que j'ai mal cherché si ça avait déjà été abordé dans la communauté? Je suis en train d'expérimenter avec un VPS mais je ne suis quand de même pas le premier à tester un mount d'un backup quand même...
Bon weekend!
Hugues
Bonjour,
Personnellement je dirais que c’est le travail de l'administrateur du serveur de savoir comment gérer son serveur.
Le guide de OVH indique les informations de base, je trouve que c'est pas à OVH je faire un guide pour tous les OS et tous les FS (FileSystem) qui sont disponibles sur le marché, sinon entre EXT4/XFS/ZFS/BTRFS/BCACHEFS
>Je suis en train d'expérimenter avec un VPS mais je ne suis quand de même pas le premier à tester un mount d'un backup quand même...
Sur ce forum, si (visiblement).
Personnellement je ne ferais jamais confiance a un système de backup que je ne maitrise pas (== géré par un autre), si je fais des backup c'est moi qui met le système en place et sait comment il fonctionne et comment restaurer le système en cas de besoin.
À toutes fins utiles je rappelle que c'est au finale à l'administrateur du serveur de tout mettre en place pour garantir la sécurité de ces données, car aucun système n'est infaillible et surtout derrière c'est vous qui serez en première ligne en cas de problème, pas OVH.
Et les évènements de ces 15/20 dernières années prouvent que tout peut arriver, que ce soit un incendie, éclaire, éruption solaire (c'est surtout les effets indirects), coupure de courant, problème matériel, erreur humaine, problème logiciel voir cyberattaque.
Note : tout ceci est mon avis perso, vu que c'est mon métier.
Cordialement, janus57
Bonjour,
Tout à fait d'accord. Je prévois encore d'autre sauvegardes vers d'autres machines que je gère. Mais vu que c'est 'offert' dans le package VPS je voulais quand de même voir si ça marche.
bav,
Hugues